Part 1: Dismiss breaks HTTP Semantics

Part 1 currently has the following requirements:

Requirement 112

• The server SHALL support the HTTP DELETE operation at the path /jobs/{jobID}.

Requirement 113

• A: If the job is currently in the accepted or running state, then the server SHALL set the status of the job to dismissed.
• B: If the job is currently in the successful, failed or dismissed state, then the server SHALL remove the job and it SHALL no longer be accessible via the Processes API.

That approach violates HTTP semantics, since DELETE requests must be idempotent. That is, the result of one or two DELETEs on a running job must be the same end result, but currently is different (one DELETE: dismissed, two DELETEs: removed). As a result, the request is not idempotent as required by RFC 9110 (see the Method Registry).

The underlying reason is that the same request is used with two different semantics, which is not a good API design.

Potential options:

• Change req 113 to "remove the job, cancelling first if necessary";
• leave removal up to the server;
• model dismissal as PUT /jobs/{jobID}/status (idempotent) or POST /jobs/{jobID}/dismiss, reserving DELETE for removal.