8 ms·

> I get so exhausted listening to people talk about http semantics, and arguing about the restfulness of different approaches. I'm with you this far. > From a

> I get so exhausted listening to people talk about http semantics, and arguing about the restfulness of different approaches. I'm with you this far. > From an implementation point of view, the difference between a POST, GET, and QUERY with a body is...trivial. Sadly the difference is not trivial at all. I suppose if you're implementing an application-specific HTTP server that directly understands the application's semantics then the difference between these is trivial enough. But for the client the difference is not trivial at all, and the clients are bound to be off-the-shelf in many cases. And for an off-the-shelf HTTP server framework the difference may not be so trivial either.

chrsig 5y ago
I've stared at enough http where the only difference to me is GET /foo HTTP/1.1\rnHost: example.com\rn\rn{"foo":"bar"} POST /foo HTTP/1.1\rnHost: example.com\rn\rn{"foo":"bar"} QUERY /foo HTTP/1.1\rnHost: example.com\rn\rn{"foo":"bar"} If it's a possibility that potential clients might refuse to do something like a GET with a body...don't use that as part of your api. Or make the endpoint respond identically to a GET with a body as a POST with a body. Similarly if you're working in a http server framework that makes such a thing difficult. At the end of the day, I care a hell of a lot more about how well the api is documented than I do about any of it's particular semantics.
- cryptonector 5y ago
  You're looking at implementing HTTP itself. If you use an off-the-shelf implementation, it may well have encoded the semantics specified by the RFC. And yes, I've seen proxies that don't support GET with a body.
  - chrsig 5y ago
    Well, if you look back to my original quote... > From an implementation point of view, the difference between a POST, GET, and QUERY with a body is...trivial That said, I'm sure you're right, and there are proxies that don't support a GET with a body. It's an inadvisable thing to implement if there's a chance that your clients may not be able to support it. It's also really easy to just send a POST request with a body instead. Where I get exhausted is when people start complaining that POSTing a body for something like a search query isn't restful. No, it's not, but it's not worth a heck of a lot of discussion either. In that respect, I'm happy that QUERY is being added, so it can hopefully resolve the distaste that the dogmatic experience. But that's really the only thing that makes me excited about it. Other than hushing the dogmatic, it doesn't really add much value.
    - cryptonector 5y ago
      In the absence of QUERY, the only way to do large queries is by POSTing them. Anyone who complains that that is not RESTful can go get in the time machine and implement QUERY in 1993.

chrsig 5y ago

I've stared at enough http where the only difference to me is GET /foo HTTP/1.1\rnHost: example.com\rn\rn{"foo":"bar"} POST /foo HTTP/1.1\rnHost: example.com\rn\rn{"foo":"bar"} QUERY /foo HTTP/1.1\rnHost: example.com\rn\rn{"foo":"bar"} If it's a possibility that potential clients might refuse to do something like a GET with a body...don't use that as part of your api. Or make the endpoint respond identically to a GET with a body as a POST with a body. Similarly if you're working in a http server framework that makes such a thing difficult. At the end of the day, I care a hell of a lot more about how well the api is documented than I do about any of it's particular semantics.

cryptonector 5y ago
You're looking at implementing HTTP itself. If you use an off-the-shelf implementation, it may well have encoded the semantics specified by the RFC. And yes, I've seen proxies that don't support GET with a body.
- chrsig 5y ago
  Well, if you look back to my original quote... > From an implementation point of view, the difference between a POST, GET, and QUERY with a body is...trivial That said, I'm sure you're right, and there are proxies that don't support a GET with a body. It's an inadvisable thing to implement if there's a chance that your clients may not be able to support it. It's also really easy to just send a POST request with a body instead. Where I get exhausted is when people start complaining that POSTing a body for something like a search query isn't restful. No, it's not, but it's not worth a heck of a lot of discussion either. In that respect, I'm happy that QUERY is being added, so it can hopefully resolve the distaste that the dogmatic experience. But that's really the only thing that makes me excited about it. Other than hushing the dogmatic, it doesn't really add much value.
  - cryptonector 5y ago
    In the absence of QUERY, the only way to do large queries is by POSTing them. Anyone who complains that that is not RESTful can go get in the time machine and implement QUERY in 1993.