lschuermann
commented
1 month ago For posterity's sake: I was slightly concerned whether DELETE is the appropriate HTTP verb here, because the resource will not actually vanish after this operation (a running job will just be stopped / canceled). However, looking up the specification for DELETE in RFC 7231, this seems to be fine:
[4.3.5](https://www.rfc-editor.org/rfc/rfc7231#section-4.3.5). DELETE
The DELETE method requests that the origin server remove the
association between the target resource and its current
functionality. In effect, this method is similar to the rm command
in UNIX: it expresses a deletion operation on the URI mapping of the
origin server rather than an expectation that the previously
associated information be deleted.
If the target resource has one or more current representations, they
might or might not be destroyed by the origin server, and the
associated storage might or might not be reclaimed, depending
entirely on the nature of the resource and its implementation by the
origin server (which are beyond the scope of this specification).
Likewise, other implementation aspects of a resource might need to be
deactivated or archived as a result of a DELETE, such as database or
gateway connections. In general, it is assumed that the origin
server will only allow DELETE on resources for which it has a
prescribed mechanism for accomplishing the deletion.
This PR opens the following endpoint:
DELETE /api/v1/job/:idto cancel a jobas previously, in #20, the switchboard was missing the code to assign the
stop_job:<JOB_ID>permission. Additionally, it makes some minor changes in the switchboard configuration, and updates the example configuration file to the new optional dev-mode-only SSL config.