4 ms·

I’d like to see this (or something like it) ship. Right now the two most common alternatives are: 1) GET, but base64 encode a json payload as a query param. Ma

by yashap 3y ago

I’d like to see this (or something like it) ship. Right now the two most common alternatives are: 1) GET, but base64 encode a json payload as a query param. Main downsides are that you can hit URL size limits, it makes the client and server slightly more complex (base64 encode/decode), and it sucks with browser dev tools - can’t nicely inspect the request in the browser, have to copy and decode it 2) Use POST to search. This confuses both machines and people. On the machines side, it doesn’t play well with caches, retry middleware, etc. On the people side, it confuses developers, ppl monitoring metrics, etc. - you think it’s creating something but it isn’t. Basically goes against all the reasons we have separate GET/POST/PUT/PATCH/DELETE methods in the first place Yeah, we have workarounds, but they have pretty significant downsides. I’d rather have this new method. Honestly, I think one of the main reasons ppl reach for RPC frameworks over RESTful APIs is the awkwardness around making search queries - this would really fix that issue.

afiori 3y ago
I would say that people should be more open to using HTTP in non-REST ways. Sometimes you want to send a request and receive a response, with arbirtrary restrictions and side effects that suit your cases. There are a lot of good reason for rest to exists, but also sometime you want to POST /open-garage-door?t=5-minutes and call it a day
- yashap 3y ago
  Sure, the odd RPC style HTTP call is fine - not everything is cleanly modelled as a resource. But the lack of a clean way to make GET requests with a more complex request payload is simply a wart/shortcoming in the HTTP protocol IMO, and one that’s very correctable. Sucks to have to abandon RESTfulness even when I have a very “clean fit for the resource model” call to make, but the request body is too complex/large for HTTP query params.

by yashap 3y ago

afiori 3y ago

I would say that people should be more open to using HTTP in non-REST ways. Sometimes you want to send a request and receive a response, with arbirtrary restrictions and side effects that suit your cases. There are a lot of good reason for rest to exists, but also sometime you want to POST /open-garage-door?t=5-minutes and call it a day

yashap 3y ago
Sure, the odd RPC style HTTP call is fine - not everything is cleanly modelled as a resource. But the lack of a clean way to make GET requests with a more complex request payload is simply a wart/shortcoming in the HTTP protocol IMO, and one that’s very correctable. Sucks to have to abandon RESTfulness even when I have a very “clean fit for the resource model” call to make, but the request body is too complex/large for HTTP query params.