4 ms·

You can do that (adding body to GET) but you might generate some restrictions for using the cire. Example from the article: > When working with HTTP, there’s s

by gls2ro 5y ago

You can do that (adding body to GET) but you might generate some restrictions for using the cire. Example from the article: > When working with HTTP, there’s servers but also load balancers, proxies, browsers and other clients that all need to work together. The behavior isn’t just undefined server-side, a load balancer might choose to silently drop bodies or throw errors. There’s many real-world examples of this. fetch() for example will throw an error.

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 ago
  While 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.

by gls2ro 5y ago

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 ago
While 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.