CODEWITHSUNDEEP
rest
reactor
reactor

Reputation: 1931

what is correct RESTful endpoint

I have one a PUT endpoint that's specifically for updating a user's location: /api/v1/user/{id}/location and another PUT endpoint for updating another property of the user's busy state /api/v1/user/{id}/availability

I was wondering if this is an antipattern since I'm ultimately updating the state of the user on both. That is, should I instead just have a single PUT endpoint: /api/v1/user to be closer to RESTfulness?

I'd prefer to have separate endpoints as a way to guarantee that I'm only updating that one user property, while consolidation makes me lose that extra level of clarity and purpose. Thank you!

Upvotes: 1

Views: 60

Answers (2)

Sreeram Chinta
Sreeram Chinta

Reputation: 21

It appears that a HTTP "PATCH" would be a better option in your scenario.

https://www.restapitutorial.com/lessons/httpmethods.html

Above page recommends a PATCH method vs. PUT if the entire resource is not updated, instead just a few parts of a specific resource are updated.

For instance, a patch with a JSON body with the specific properties to be updated can be sent and processed on the server. The request body would have either a location or the availability or both.

Finally, the PATCH operation is requested against the specific resource ID which is /api/v1/user/{id}.

Upvotes: 2

inf3rno
inf3rno

Reputation: 26139

You need to focus on the operation you want to do and forget about endpoints. Operations would look something like moveUser(userId, location), makeUserBusy(userId), makeUserAvailable(userId). If you check, these change the resource state and all of them are idempotent and it is obviously not deletion, so your HTTP method for all of them will be PUT or PATCH. After you know the verb, you can think about the noun for your resource. (Though this is the budget version of REST, because in the real one the URL does not matter. Thanks to HATEOES constraint the client should be able to discover it. But let's say we do this to understand better the URIs in our logs.) With PATCH you can do partial modification, so the noun can be the user itself or user state, something like PATCH /api/v1.0/user/{userId} {"location":"..."} or PATCH /api/v1.0/user/{userId} {"isBusy":true} would suffice. In the case of PUT you go a level deeper and change the properies: PUT /api/v1.0/user/{userId}/location "..." or PUT /api/v1.0/user/{userId}/isBusy true. Both are allowed and ok. All you need to do is document them especially if you don't want to fulfill the HATEOAS constraint.

Upvotes: 2

Related Questions