4 ms·

"Correct POST /accounts/4402278/close" bullshit. POST should not contain all details in URL. POST can have body and each query should not be unique. Stopped

• zeveb 10y ago
  I disagree. In the example, account 4402278 is a resource represented at /accounts/4402278; actions on that resource should be performed … on that resource, not on some other resource (e.g. all accounts, at /accounts). This also gives increased future-proofing, since someday one might have uncloseable accounts; those accounts could still live under /accounts, but would simply have no /close endpoint (as opposed to having /accounts/close, which sometimes works and sometimes doesn't).
  • deleted 10y ago
    [deleted]
  • EugeneOZ 10y ago
    "close" is a verb, so it's not a resource, it's a method and 4402278 is just argument of that method.
• recursive 10y ago
  URLs should... well... locate a resource. The resource is an account.
  • EugeneOZ 10y ago
    Only when it's GET request. This request will not return you any resource information, with id if account or without.
    • amk_ 10y ago
      What about DELETE?
      • EugeneOZ 10y ago
        DELETE is for deletion only, this request can't have body, so only what we can do is send id in query. When we want to remove multiple resources we either should send multiple requests (what is slow), or combine multiple ids in query (what is ugly and non-idiomatic).
    • recursive 10y ago
      In your mind, what does URL stand for? It's an acronym.
      • EugeneOZ 10y ago
        Do you really expect to get resource data when you send POST or DELETE request? If yes, then web (and REST) is not as perfect as you expect.
• blowski 10y ago
  The REST design pattern does require that your URLs are structured in this way, and I don't think that's really open to debate. Whether or not all HTTP APIs need need to be RESTful is a different issue.
• darkhorn 10y ago
  Yeah, just PATCH /accounts/4402278 with parameter ACTIVE: 0