37 ms·
Sorry I wasn't clear. The lack of defined behaviour for bodies in GET is an example of harms arising from REST obsession. It's clearly a useful thing but becaus
by UglyToad 5y ago
Sorry I wasn't clear. The lack of defined behaviour for bodies in GET is an example of harms arising from REST obsession. It's clearly a useful thing but because it goes against the intended design it's treated as a bad idea. It just feels like REST discussions are where the strongest divide between pragmatism and bikeshedding occur.
- cryptonector 5y agoWhile REST obsession is a thing, the "lack of defined behaviour for bodies in GET" arises from the fact that it's defined to not have a request body, therefore there exists a lot of code that assumes it has no request body and acts accordingly, leading to interoperability problems. You have to separate HTTP, the spec, from REST the philosophy. REST says you should use HTTP status codes. HTTP doesn't obligate you to use the full range of its status codes -- you can code up a resource that always returns 200 for POSTs, and that's fine as far as HTTP goes, and not as far as REST goes.
- dragonwriter 5y ago> REST says you should use HTTP status codes No, it doesn't, though leveraging the semantics of the underlying communications protocol (such as response codes when running over HTTP) is a convenient way to satisfying the “self-describing messages” constraint of REST. > you can code up a resource that always returns 200 for POSTs, and that's fine as far as HTTP goes, and not as far as REST goes. The only reason it would be even slightly problematic for REST is if it were inconsistent with the semantics of HTTP. Which, of course, returning 200 for anything but success would be.