5 ms·
That's only true if you ignore the fact that operations in HTTP have semantics attached. (Or at least that was the intent. The reality is probably that they act
by lomnakkus 10y ago
That's only true if you ignore the fact that operations in HTTP have semantics attached. (Or at least that was the intent. The reality is probably that they actually don't in practice. Plus, as others in this thread point out: The semantics may not actually make any sense.)
- naasking 10y agoWhat semantics can't be captured by only GET and POST?
- lomnakkus 10y agoI 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. :)