3 ms·

I really, really, hate REST prescriptivism. I'm going to return 200 from POSTs and want to use request bodies for GET requests to do filtering. We may as well u

I really, really, hate REST prescriptivism. I'm going to return 200 from POSTs and want to use request bodies for GET requests to do filtering. We may as well use POST for updates. REST doesn't work for my use-case or probably most use-cases but people seem to treat it like an article of faith even when it forces a completely bass-ackwards design. SOAP was the pinnacle of API design.

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.
theandrewbailey 5y ago
In my view, REST is how HTTP is supposed to be used. If you're going to POST and 200 everything, you're probably re-inventing things that HTTP already has well-tested and already implemented infrastructure for. If HTTP already has a clear solution for what you're doing, you should use that instead of building it yourself on top of HTTP.
- nrmitchi 5y ago
  It's not even just that, but by avoiding the well-known standards of how HTTP behaves, you're going to find yourself fighting with any tool/system that is based on those standards.
akvadrako 5y ago
You can't use bodies in GET requests in some popular browsers, so better just use POST for everything you don't want cached.
- leetrout 5y ago
  And if you are me use openresty and cache the POSTs too

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.

theandrewbailey 5y ago

In my view, REST is how HTTP is supposed to be used. If you're going to POST and 200 everything, you're probably re-inventing things that HTTP already has well-tested and already implemented infrastructure for. If HTTP already has a clear solution for what you're doing, you should use that instead of building it yourself on top of HTTP.

nrmitchi 5y ago
It's not even just that, but by avoiding the well-known standards of how HTTP behaves, you're going to find yourself fighting with any tool/system that is based on those standards.

akvadrako 5y ago

You can't use bodies in GET requests in some popular browsers, so better just use POST for everything you don't want cached.

leetrout 5y ago
And if you are me use openresty and cache the POSTs too