6 ms·

Yeah I'm saying this is wrong :\ This isn't how REST is supposed to work

by fzilla 10y ago

blowski 10y ago
Can you give an example here of how you think it should work, please. This is one area of REST with which I have a lot of trouble.
- qyv 10y ago
  For the deposit/withdrawal/transfer set, depending on the specifics of how they are actually moving the amounts around, would likely be best served as their own resource. Since a deposit/withdrawal is just a transfer anyways, just having "/transfer" would be likely be good. The connotation here is that the client is creating a transfer on the server. The body for this request could take the relevant account numbers (you need two accounts), and the sign on the amount would denote if the amount is being deposited or withdrawn.
  - blowski 10y ago
    So I would make a request like: POST /transfer from_account_id=12345&to_account_id=67890&amount=10 Perhaps I've misunderstood your comment, as I don't really understand why this is better than the original: POST /accounts/12345/transfer to_account_id=67890&amount=10 or even: POST /accounts/12345/withdraw amount=10
    - qyv 10y ago
      Having the /account/:accountid/transfer is not a terrible idea, but I would avoid it because the transfer resource is able to stand on it's own with making it tied to a single account resource. The key point though is that 'transfer' is the resource to perform all three of the original deposit/withdrawal/transfer actions.
- 33degrees 10y ago
  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/4502278/deposits" to create a new deposit, which would then live at a URL such as "/account/4502278/deposits/87162". And instead of separate subresources for all of these different transaction, it could just be one "transaction" subresource. In the case of closing an account, it depends on what actually happens when you do so, but I would normally have a "status" attribute and use PATCH to update that.
  - 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.
goostavos 10y ago
Ah, and therein lies the classic problem. Nobody is doing REST "right," but I'm yet to see anyone point to a de-facto example. Fielding's dissertation isn't a spec, which pretty much means everyone can come up with their own little slice of how it should be done and then say they're doing it right. The true rule of REST: whoever is blogging/commenting about it at the time is doing REST right, all others are confused and incorrect.
- electrotype 10y ago
  Reminds me of Agile...
- meddlepal 10y ago
  There is a lot ceremony with "REST". Considering REST is architectural pattern and not even an HTTP-specific one I find it very suspect whenever someone says REST API's must use particular HTTP methods or structure URL's in a specific way. Conventionally that is true and it certainly reduces friction in your API by adhering to common conventions.

Yeah I'm saying this is wrong :\ This isn't how REST is supposed to work

by fzilla 10y ago

Yeah I'm saying this is wrong :\ This isn't how REST is supposed to work

Can you give an example here of how you think it should work, please. This is one area of REST with which I have a lot of trouble.

qyv 10y ago
For the deposit/withdrawal/transfer set, depending on the specifics of how they are actually moving the amounts around, would likely be best served as their own resource. Since a deposit/withdrawal is just a transfer anyways, just having "/transfer" would be likely be good. The connotation here is that the client is creating a transfer on the server. The body for this request could take the relevant account numbers (you need two accounts), and the sign on the amount would denote if the amount is being deposited or withdrawn.
- blowski 10y ago
  So I would make a request like: POST /transfer from_account_id=12345&to_account_id=67890&amount=10 Perhaps I've misunderstood your comment, as I don't really understand why this is better than the original: POST /accounts/12345/transfer to_account_id=67890&amount=10 or even: POST /accounts/12345/withdraw amount=10
  - qyv 10y ago
    Having the /account/:accountid/transfer is not a terrible idea, but I would avoid it because the transfer resource is able to stand on it's own with making it tied to a single account resource. The key point though is that 'transfer' is the resource to perform all three of the original deposit/withdrawal/transfer actions.
33degrees 10y ago
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/4502278/deposits" to create a new deposit, which would then live at a URL such as "/account/4502278/deposits/87162". And instead of separate subresources for all of these different transaction, it could just be one "transaction" subresource. In the case of closing an account, it depends on what actually happens when you do so, but I would normally have a "status" attribute and use PATCH to update that.
- 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.

goostavos 10y ago

Ah, and therein lies the classic problem. Nobody is doing REST "right," but I'm yet to see anyone point to a de-facto example. Fielding's dissertation isn't a spec, which pretty much means everyone can come up with their own little slice of how it should be done and then say they're doing it right. The true rule of REST: whoever is blogging/commenting about it at the time is doing REST right, all others are confused and incorrect.

electrotype 10y ago
Reminds me of Agile...
meddlepal 10y ago
There is a lot ceremony with "REST". Considering REST is architectural pattern and not even an HTTP-specific one I find it very suspect whenever someone says REST API's must use particular HTTP methods or structure URL's in a specific way. Conventionally that is true and it certainly reduces friction in your API by adhering to common conventions.