Part 1: Dismiss breaks HTTP Semantics

[cportele]

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.

[fmigneault]

I think the word "remove" here is misleading, but it meant as the same thing in both cases. The job becomes unavailable (410 Gone or 404 Not Found) on subsequent calls. Using "cancel" would remove the possible confusion.

Removal (as in cleanup/disposition strategy) is already up to the server by design, as indicated by the NOTE, because that is an implementation/policy choice (eg: preserving data X days for traceability, legal, retry/cache-execute, etc.)

ogcapi-processes/core/requirements/dismiss/REQ_job-dismiss-status.adoc

Lines 18 to 22 in fcb1926

	NOTE: This standard makes no statements regarding the disposition strategy of artifacts created by a job once a job has been
	dismissed and is no longer accessible via the Processes API. Responses to dismissed jobs and their artifacts can
	optionally employ the corresponding <<per_core_job-results-exception_job-gone,/per/core/job-results-exception-job-gone>>
	and <<per_core_process-exception_job-gone,/per/core/process-exception-job-gone>> approaches to indicate their unavailability.

https://docs.ogc.org/DRAFTS/18-062r3.html#per_core_process-exception_job-gone

I would rather not do the PUT approach since it introduces conflicting situations with Part 4:
https://docs.ogc.org/DRAFTS/24-051.html#req_job-management_update_response-locked

[cportele]

So, if the state of the job and the API responses are identical whether DELETE on the running job has been sent once or twice (GET results in 404/410 in both cases), then req 113 A and B can collapsed to "remove the job, cancelling first if necessary" - the first option.

[bpross-52n]

SWG Meeting from 2026-08-31: We will remove Option A from Requirement 113.