4 ms·

One way to approach it would be to have consider deposits, withdrawals, and transfers as subresources of a specific account. So you could POST to "/account/4502

• blowski 10y ago
  Your PATCH example makes sense, so I should do something like (depending on your opinions of how to do PATCH requests): PATCH /users/123 [{ "op": "replace", "path": "/accounts/12345/status", "value": "closed" }] I personally think that's less readable than the original, but I agree that it seems to more closely fit the REST standard. With the deposit, I don't really understand what's changed here from the original. To me, it just looks like deposit has been pluralised, and everything else is the same: POST /account/12345/deposits amount=10
  • 33degrees 10y ago
    I would simply PATCH { "status" : "closed" }, as that's how PATCH works in rails. Regarding the deposits, the difference is that 'deposits' is a collection of deposit resources vs 'deposit' as a verb. I think in this case it makes a lot of sense to do it that way, as you can then GET /account/12345/deposits and see all the deposits ever made.
    • blowski 10y ago
      OK, so the original one used a verb at the end of the URL, whereas it should have used a noun. In practice, this wil often means that the URL is almost identical - here for example, it will be: POST /accounts/12345/deposits instead of: POST /accounts/12345/deposit Perhaps your example would be more obvious if it had different terms, where the noun and verb were more distinct - maybe 'game' and 'play'. Even then, from experience, you end up with some horrible URLs just so it's RESTful. While I try to follow REST, I balance it against making the API readable by human beings.
      • dragonwriter 10y ago
        > you end up with some horrible URLs just so it's RESTful No, you don't. RESTful applications use URLs as opaque identifiers, and communicate all information via resource representations. Communicating information via resource identifiers is decidedly not-RESTful, so any particular URL structure chosen to communicate specific information in the URL is, ipso facto, not RESTful.
        • blowski 10y ago
          I'll give a specific specific example from my own experience of building an intranet. I had documents that people could print. POST /documents/12345/print To me, while this was not RESTful, it was the most readable way I came up with. When I asked somebody who had more experience with REST than me, he suggested I build the URL like this: POST /users/123/print-jobs url=/documents/12345 Doing this, I would have to add validation to make sure it was a printable URL. Also, there was no corresponding GET request, so it seemed pointless. And it made the code weirder, as the 'print' action would be separated from the rest of the actions on documents. So how would you do it instead? Or you would do it the same way, and just not worry about the problem? It seems that consensus on how to do REST breaks down when you have custom verbs.
          • 33degrees 10y ago
            Why not POST /documents/12345/print-jobs And you say there's not corresponding GET request, but maybe there should be? Perhaps you'd want to list print jobs, get the status of a particular job, and maybe cancel it?
            • blowski 10y ago
              I guess because it's not how I talk. I say "I'll print this document", not "I'll send this document to the printer". I don't have a print queue because nobody has ever asked for one or shown the need for one.
          • dragonwriter 10y ago
• jchoca 10y ago
  A less related question: how do you decide between adding something as a property vs. creating a new subresource?
  • 33degrees 10y ago
    Good question, I guess it's pretty much the same as deciding if something is a new field or a new table in a database?