Styles: suggested styleId when creating a style?

[cportele]

From the discussion in the chat on day 3:

Styles extends on the generic Create/Replace/Delete requirements class, i.e., styles are always created with POST and the server assigns the styleId. The server is free to parse the submitted stylesheet to determine a meaningful styleId, if it wants, but that is not possible in style encodings that do not include an identifier.

Maybe add a HTTP header that clients could use to suggest a styleId with a POST request. The server would be free to ignore the suggestion.

I will see, if such a header is already in use somewhere.

[pomakis]

That seems like an awkward requirement. What's wrong with using HTTP PUT for this? RFC 2616 states (re: HTTP PUT) "If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI.". For example, the CubeWerx implementation accepts an HTTP PUT /styles/{styleId} request to create (or replace) a style with a specific ID.

[cportele]

@pomakis - Maybe talk to your colleague @pvretano 😁? Here is a link to the discussion that resulted in the current requirements: https://github.com/opengeospatial/ogcapi-features/issues/329.

[pomakis]

@cportele, that requirement is specifically for the creation of a new vector feature "since assignment of feature ids is up to the server". There's no such constraint for styles.

[cportele]

@pomakis - No the requirement is from a requirements class that is for create/replace/delete of resources in general (although it sits in Features), there is a separate one in the document that specializes the requirements for feature resources. The rule that only POST is used for create is already in the general class. But, of course, that could be discussed/changed again.

[pomakis]

@cportele, if this is true then this decision definitely needs to be revisited. HTTP PUT is the standard way of allowing a client to create a resource with a client-defined URI. HTTP POST is for situations where the server should assign a URI. Feature IDs are usually server specific, so it makes sense for the creation of a new feature through HTTP POST. But to ban the creation of other OGC API resources through HTTP PUT, and define some other awkward way of allowing the client to indicate the desired ID, would be silly.

[cportele]

Related: https://github.com/opengeospatial/ogcapi-features/issues/595

[jeffharrison]

Note - On 5 Oct 2021 SWG discussed aspects of this Issue. TBC in future sessions.

[cportele]

Meeting 2021-11-02: Wait for the update to the conformance class in Features. Then we will support Create using PUT in Styles.