Neilos
Neilos

Reputation: 2746

REST: update a resource with different fields requiring different user permissions

I have an endpoint /groups

I can create a group by POSTing some info to /groups

A single group can be read by /groups/{id}

I can update some fields in the group by POSTing to /group/{id}

HOWEVER I have different fields that are needed to be updated by users with different permissions, for instance: A group might have the structure

{
 "id": 1,
 "name": "some name",
 "members": [
  {
   "user_id": 456,
   "known_as": "Name 1",
   "user": { /* some user object */},
   "status": "accepted",
   "role": "admin",
   "shared": "something"
  },
  {
   "user_id": 999227,
   "known_as": "Name 1",
   "user": { /* some user object */},
   "status": "accepted",
   "role": "basic",
   "shared": "something"
  },
  {
   "user_id": 9883,
   "known_as": "Name 1",
   "user": { /* some user object */},
   "status": "requested",
   "role": "basic",
   "shared": "something"
  }
 ],
 "link": "https://some-link"
}

As an example I have the following 3 operations for the /group/{id}/members/{id} endpoint:

My options are this:

  1. Should I allow all updates to be done by POSTing to /group/{id}/members/{id} with a subset of the fields for a member and throw an unauthorized error if they try to update a field that they aren't allowed to update?
  2. Or should I break each operation into say /group/{id}/members/{id}/role, /group/{id}/members/{id}/shared and /group/{id}/members/{id}/status? The problem with this is that I don't want to have to make lots of requests to update all the fields (I imagine that there will end up being quite a lot of them).

So just for clarification my question is: Is it considered proper REST to do my option 1 where I can post updates to an endpoint that may fail if you try to change a field that you aren't allowed to?

Upvotes: 0

Views: 452

Answers (1)

cshu
cshu

Reputation: 5954

In my opinion, option 1 is much better than option 2.

As you said option 2 is a waste of bandwidth.

More importantly, with option 1 you can easily implement an atomic update (update "all-or-nothing"). It should either complete successfully or fail entirely. There should never be a partial update.

With option 2 it's very likely the update can be implemented to complete some request successfully and reject another request, even if the two requests are considered a single operation.

Upvotes: 2

Related Questions