4 ms·
> Or an unending number of other interpretations and when someone joins the team and raises endless arguments with you about how what is already working isn't
by mgkimsal 9y ago
> Or an unending number of other interpretations
and when someone joins the team and raises endless arguments with you about how what is already working isn't REST, because their interpretation is different, you have problems.
and when you have a client that insists that you're not following REST conventions because your endpoints take POST for everything and don't take actual PUT commands, and they are not going to retool their interpretation of REST to match yours, you have problems.
These problems would exist anyway - interacting with other people usually brings some problems with it - but putting things under this banner of REST implies that there is some 'right' way of doing things which contributes to the interaction problems.
Just acknowledging "hey, this could have been done 4 ways, this is the way that was chosen, deal with it" - regardless of whether the REST acronym is involved or not - should be the way to go, but an implied 'standard' creates more hurdles.
- jchw 9y agoI could say the exact same thing about RPC. API design is difficult, largely in part because programmer types often refuse to acknowledge the "design" part. REST actually improves this by providing a sane set of ideas to base your web API design off of. It only makes it worse if you want it to. REST has plenty of nice advantages people ignore too, like for example, often with REST APIs, ACL and authentication can be handled much easier because you can use URLs as a primitive for permissions.