7 ms·

A simple POST based API? What is this blasphemy?

• smizell 11y ago
  It is interesting that you request the /get_account link with a POST method.
  • ajkjk 11y ago
    As systems grow you always end up wanting to parameterize GET apis with things that you can't reasonably continue to stuff into headers, matrix params, and a wonky URL (in my experience).
    • tlb 11y ago
      And especially, browsers limit URLs to as small as 2 kB. They go into more detail on this design decision here: https://blogs.dropbox.com/developers/2015/03/limitations-of-the-get-method-in-http/ https://blogs.dropbox.com/developers/2015/03/limitations-of-...
    • dragonwriter 11y ago
      Which is why we need to get rid of the WebDAV baggage around the SEARCH method [0] and establish a general-purpose, safe/idempotent HTTP method that accepts a message body to supply parameters rather than using URL query strings; a draft RFC for such a method exists. [1] [0] https://tools.ietf.org/html/rfc5323 https://tools.ietf.org/html/rfc5323 [1] https://tools.ietf.org/html/draft-snell-search-method-00 https://tools.ietf.org/html/draft-snell-search-method-00
    • lucian1900 11y ago
      GET requests can have a body. Some clients fail at handling this and you have to use method overrides, though.
      • prodigal_erik 11y ago
        We have fifteen years worth of client and proxy implementations that do not support GET with a request body. This ill-conceived spec change violates "be conservative in what you send" just to avoid adding a new idempotent request method that actually defines usable semantics for its body.
      • awinder 11y ago
        GET requests can have a body but by spec they aren't supposed to parse it with the request https://groups.yahoo.com/neo/groups/rest-discuss/conversations/messages/9962 https://groups.yahoo.com/neo/groups/rest-discuss/conversatio...
      • sk5t 11y ago
        If I had to consume an API with entity-body-having GETs, I would definitely conclude the designers had no practical experience in the field, and had read about this obscure possibility somewhere...
    • cunac 11y ago
      in this case there is no reason to do that and you lose all possibilities of using cache if that is desirable GET /users/@me/accounts/:id --> specific user account GET /users/@me/accounts --> all user accounts would suffice and would read naturally , it would also give you ability for other user with appropriate credentials (admin kind) to see some other user account information yes, very disappointed with design decisions (I understand that from a purist perspective URI is opaque but well named URIs help communication with people)
      • ajkjk 11y ago
        My point is that in complex systems 'get' use cases come up that don't fit well in urls. Suppose you have too many accounts to list, so you start taking predicates in the API, or you start returning a pagination token that's passed back in on a subsequent requests. You quickly overwhelm URIs and have to start serializing complex objects in headers or query params. Eventually you give up and switch to POST so you can just post a json body and be done with it.
        • cunac 11y ago
          I do build a complex systems and pagination payload always have links to prev/next etc. , POST for GET would kill all client side and server side caching we leverage and would make system really hard to scale. We still didn't run into compelling case to use POST for this type of fixed queries. What you are talking is ad hoc search capability and that is usually done differently either by posting content type which indicates search payload or using different generic URI for search queries within a whole system
• conradk 11y ago
  As long as everything is well documented, I don't see the problem. With most languages, you'll probably want to use an SDK anyway. What's the problem with a POST based API?
  • waterside81 11y ago
    pixie_ was being sarcastic - alluding to how "RESTful" APIs with the wide array of verbs is en-vogue in some circles.