Separate requirements classes for create, replace, and delete support

[duckontheweb]

We are currently building a service based on OGC API - Features with a requirement that Features be immutable once created. In other words, we want to support only the CREATE operation without supporting REPLACE or DELETE. However, I do not see a way to publish this capability using a requirements class since the http://www.opengis.net/spec/ogcapi-features-4/1.0/req/create-replace-delete requires that all 3 be implemented, so I have simply omitted the requirements class.

Could we consider splitting these into separate requirements classes so that services could more accurately and atomically represent their CRUD capabilities?

[pvretano]

... and the OPTIONS method rears it's head once again! ;) Sorry ... inside joke. See issue #505 .

I'm OK with splitting create-replace-delete into separate conformance classes however the OPTIONS method might also be considered since it offers more fine-grained control over the methods supported particular endpoints. Using your create-only use case, if a client used the OPTIONS method at the /collections/{collectionId}/items endpoint they would see that the GET and POST methods were supported and would know that feature instances could be created via POST. If the client used the OPTIONS method at the /collections/{collectionId}/items/{featureId} endpoint they would see that the DELETE and PUT methods were NOT supported and would thus know that features cannot be deleted or replaced.

[duckontheweb]

I'm OK with splitting create-replace-delete into separate conformance classes however the OPTIONS method might also be considered since it offers more fine-grained control over the methods supported particular endpoints.

I think it makes a lot of sense to use OPTIONS to provide this information, but I think we should continue to use conformance classes to publicize it as well. Since clients are used to inspecting conformance classes in most other places throughout the spec I think it could be confusing to have some capabilities advertised through an OPTIONS call and some advertised through conformance classes. Ideally, the /conformance endpoint gives the client a single response that they can use to interpret the full capabilities of the service without having to make additional requests.

I'm happy to put in a PR to separate these conformance classes if that would be helpful

[cportele]

Meeting 2022-10-24:

• There are two reasons why using the conformance declaration is insufficient. Which methods are allowed will often depend on the resource (e.g., different rules for different collection) and/or the user (e.g., different rights for different users). As a result, OPTIONS seems to be the only standard mechanism to address the need.
• We need to clarify that implementations do not have to implement support for CREATE, REPLACE and DELETE. Implementations must declare the available methods using OPTIONS depending on the resource and/or user.
• In general, we could handle UPDATE in the same way, but since the representation is different it still does make sense to keep it separate.
• See also #505.
• @pvretano will work on a PR.