4 ms·

I get so exhausted listening to people talk about http semantics, and arguing about the restfulness of different approaches. From an implementation point of vi

• dylan604 5y ago
  At the end of the day, I don't care. If the API I am talking to says they respond to certain information sent via specific method, that's how I send it. Yes, we could argue till the cows come home about levels of appropriateness, but I've got better things to do with that time. Like process the data I just received from GET request sent with a body!
  • CodesInChaos 5y ago
    I think "REST" was primarily successful because people wanted a simple json-webapi, not because of its fancier principles.
    • hnfong 5y ago
      I thought "REST" was primarily successful at first because it was a reaction to the overblown XML mess in the early 2000s (that's the "X" in XHR, even though nobody uses it for that any more). I never understood why it became dogmatic though. Arguing for practicality over dogma seems like a losing battle, even in this industry where people are supposed to be relatively practical. I guess that's human nature :-/
  • polishdude20 5y ago
    Exactly. If I need to access some api, I'll just read their docs on which methods they want you to use. I never go in thinking "oh if there's a get request for this resource, there must be a post request for this resource like this".
    • hakre 5y ago
      Actually I would test the request first. And only if it doesn't work this would require the documentation, so would then test it after the functional test. If the documentation is even needed.
  • pacoverdi 5y ago
    You'd like my APIs, I keep defining DELETE endpoints with request bodies even though OpenAPI tools scream warnings at me :) Doing a POST on a /delete endpoint seem unnatural and I prefer serializing complex objects to JSON rather than to a query string.
• cryptonector 5y ago
  > 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.
• ok_dad 5y ago
  Imagine saying something like: > I get exhausted by people talking about integers, floats, and strings and arguing about the "types" of different things. From an implementation point of view, the difference between an integer, an float with or without a mantissa, or a string with numbers and decimal symbols is trivial. It has gotten to the point that... Things have meanings, and in computer science and programming those meanings can mean a performace difference or a difference in results, so I think it is very important that we start to pay attention to the "naval gazing" aspects of these things and not use a GET with a body, since there is a QUERY, and other specs which might be kinda naval-gazey. We are in a career that requires a pretty high level of strictness and we're always complaining about bugs in this or that software; then we argue that there is no meaning in certain things (only because in practice, people hadn't been strict about something like a GET request) which then leads to more bugs!
  • zestyping 5y ago
    Thank you.
  • chrsig 5y ago
    I think you may be misinterpreting my exhaustion -- I certainly agree that things have meaning. They have such a meaning that we standardize them. Thanks to the standardization and proliferation of the technology, there's generally an obvious correct choice, and a few poor arguments for others. In other words, it's generally not hard to make these things follow the Principle of Least Astonishment[0]. Every now and then there might be an interesting constraint that makes for a different choice (e.g., don't store zip code as an integer, because it may have a leading zero). The amount of verbose discussion that I observe any time rest semantics come up still baffles me. [0] https://en.wikipedia.org/wiki/Principle_of_least_astonishment https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...
  • jjav 5y ago
    > Things have meanings Some things have fundamental meaning. Like integers, floats, and strings are clearly very different things. Whether you allow this or that via PUT vs. POST or whatever is just a convention, and one that you can freely change as long as it is fully documented.
• e12e 5y ago
  > From an implementation point of view, the difference between a POST, GET, and QUERY with a body is...trivial. I'm quite certain that if I were implementing a caching proxy (or a caching client, like a browser) - I'd find the diffence rather important. That said, I'm also sure I'd have to consider special exceptions for popular software that got the details wrong. And if you're not caching, why use http anyway?
• toyg 5y ago
  > it all feels like naval gazing What did those poor ships do to you? /s It's navel gazing, as in "looking at your belly-button": https://en.wikipedia.org/wiki/Navel https://en.wikipedia.org/wiki/Navel
  • chrsig 5y ago
    They said everything's going into containers on on their way to the clouds /s Thank you for the correction, I had a good chuckle.
• perrygeo 5y ago
  Have you ever needed a cache? The difference between GET and POST starts to look very important. Even without a cache, a GET and POST describe "what the api does" in detail - will my request change state on the server? Or will it be idempotent?. Considering them to be equivalent is like saying SQL statements SELECT, INSERT or DELETE are all the same. The distinction is absolutely critical. edit: spelling