REST Anti-patterns
marcelo-cure.blogspot.com
REST Anti-patterns
1–10 of 133 posts
Re: REST Anti-patterns
#2Why is POST /accounts/4402278/close correct in the first example? According to the rest of the post, PUT should be a better option. Closing an account seems to me like its updating a resource, not creating one. Also, will calling that url close the account multiple times? POST is not supposed to be idempotent
Re: REST Anti-patterns
#3right, POST is not supposed to be idempotent. However, if you do a PUT on it, you are updating a resource, closing an account may involve more processes than only updating the given resource.
Ok, but why did I say it should be a POST even if POST is not supposed to be idempotent? In my point of view, POST should only be idempotent when creating resources, in this case we're acting in a resource, the /close is a process that happens on that resource (4402278), not a create/update/delete/retrieve. The best way to do it would be a POST in my opinion. Also, if we want to update only a piece of the resource, it should be a PATCH. PUT is supposed to update the whole resource.
Re: REST Anti-patterns
#4Why is POST /accounts/4402278/close correct in the first example? According to the rest of the post, PUT should be a better option. Closing an account seems to me like its updating a resource, not creating one. Also, will calling that url close the account multiple times? POST is not supposed to be idempotent
Or, if you really want to be dogmatic, use DELETE when destroying something...in this case the customer account.
Re: REST Anti-patterns
#5"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 reading after that.
Re: REST Anti-patterns
#6Why is POST /accounts/4402278/close correct in the first example? According to the rest of the post, PUT should be a better option. Closing an account seems to me like its updating a resource, not creating one. Also, will calling that url close the account multiple times? POST is not supposed to be idempotent
Maybe there is a closed account sub-resource? :)
Re: REST Anti-patterns
#7How your URLs read (and if you PUT or POST) is entirely unimportant if you are doing hypermedia/HATEAOS/REST as Fielding envisages it (http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...).
"If the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period."
If you're doing REST as-in JSON-over-http + a docs page, knock yourself out.
edit: Also see: http://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post
Re: REST Anti-patterns
#8These aren't really antipatterns. They're just bad design. Not all bad design is an antipattern.
Re: REST Anti-patterns
#9Why is POST /accounts/4402278/close correct in the first example? According to the rest of the post, PUT should be a better option. Closing an account seems to me like its updating a resource, not creating one. Also, will calling that url close the account multiple times? POST is not supposed to be idempotent
Or, if you really want to be dogmatic, use DELETE when destroying something...in this case the customer account.
I don't think I would assume that "close" is the same as a delete.
Re: REST Anti-patterns
#10right, POST is not supposed to be idempotent. However, if you do a PUT on it, you are updating a resource, closing an account may involve more processes than only updating the given resource. Ok, but why did I say it should be a POST even if POST is not supposed to be idempotent? In my point of view, POST should only be idempotent when creating resources, in this case we're acting in a resource, the /close is a proce…
Strictly speaking, if you do a PUT on it, you are not updating a resource, you are replacing a resource. I know you basically say the same thing, but "update" is too ambiguous in this case. That is also why PUT is idempotent: it replaces the complete state of the referred resource.
Similarly, POST is not idempotent because it modifies (part of) the resource's state while leaving it otherwise untouched.