3 ms·
I was thinking about meta-level semantics, i.e. semantics that apply to all HTTP/REST-based systems, not just one's own special snowflake :). EDIT: Though, hon
by lomnakkus 10y ago
I was thinking about meta-level semantics, i.e. semantics that apply to all HTTP/REST-based systems, not just one's own special snowflake :).
EDIT: Though, honestly, I must say that I also question the value of these things. For example, HTTP error codes are notoriously ambiguous and you usually need to transmit an actual response (and sometimes are forbidden spec-wise!) with an error code. I was just assuming the position of an advocate for HTTP/REST.
- naasking 10y ago> I was thinking about meta-level semantics, i.e. semantics that apply to all HTTP/REST-based systems, not just one's own special snowflake Yes, but these verbs often don't yield any meaningful results or see much use in my experience. Even so, this could easily be achieved by convention using just GET/POST. Consider the HTTP OPTIONS verb. If you invoke it with * as the request-URI, it's an operation that applies to the server as a whole rather than any specific resource. This provides the solution: HTTP already reserves one URI for a specific use, and we can do the same for all of the other verbs and eliminate them from the spec if we so desired, ie. OPTIONS /some/resource => GET /options?url=/some/resource
- lomnakkus 10y agoI think we agree, I was merely commenting on a techincality. :)