3 ms·
Users, for instance. If you think of users as a resource, then updating them is a PUT to /users/{id}. Fine, they can update their info. But you also need a w
by daxfohl 10y ago
Users, for instance. If you think of users as a resource, then updating them is a PUT to /users/{id}. Fine, they can update their info. But you also need a way to change their password. That's a different entrypoint. Where does it go? /users/{id}/password? Is it a PUT or a POST?
I mean, nothing here can't be worked around. Millions of sites do this just fine. But to me, the mental model just doesn't match up. The REST model tries to present a facade that everything is a "resource". In my experience, as apps get bigger, more and more things start not quite fitting that model. You end up having to justify to yourself why certain things go on certain endpoints and soon half your API is REST and half is some hacky REST-RPC hybrid anyway. Starting with an RPC model from the get-go, you avoid these problems.
And note, REST and RPC aren't technologies. REST is a form of RPC, and you can certainly roll your own RPC protocol over REST. They're merely different ways of thinking about and modeling your application.
- dragonwriter 10y ago> If you think of users as a resource, then updating them is a PUT to /users/{id}. Fine, they can update their info. That sounds a lot more like a user profile resource than a user resource. > But you also need a way to change their password. That's a different entrypoint. Or, if you have a user resource rather than separate profile I and password resources, all partial updates could go to the same resource as PATCHes. > Where does it go? If you spend a lot of time thinking about that, you probably aren't doing REST. > Is it a PUT or a POST? Is it a replacement or a new resource? Largely, that depends on your domain model, and models under which either answer (or PATCH) make sense. As long as the definitions of your resource representations tell what operations are supported, and what they mean, for endpoints represented by the relevant link relations, it really doesn't matter all that much. > The REST model tries to present a facade that everything is a "resource". In my experience, as apps get bigger, more and more things start not quite fitting that model. I can't imagine how anything could fail to fit the model, unless you assume (as REST does not) that resources must be completely independent so that an action on one resource has no effects on the state of other resources.