3

I'm fairly new to Collection+JSON. I have a bunch of questions regarding Collection+JSON and user operations.

Use Case

Having user permissions in a Collection+JSON response would be useful in telling the client what operations can be enacted on a particular object. As an example, it would allow the client to know which "buttons" to render on the user interface.

Questions

  1. Should the user's permissions be bundled into the Collection+JSON response?
  2. Should the user's permissions be bundled into a separate call to the user object?
  3. Is this beyond the scope of Collection+JSON?

Thoughts

My personal thought is that user permissions should be stored in a user object for a separation of duty, however, if this is the case then every request should then be paired with a request for a user object. This doesn't seem like a correct methodology.

Examples

In the following examples, "permissions" are represented by an integer value where 1 represents read, 2 represents create, 3 represents update, and 4 represents delete. The server will always validate the user's request, but this would make it easier for the client to know what operations can be done to the object.

1. Bundled in the response

"Permissions" could be added to the Collection+JSON specification, but this would be modifying the specification.

{
  "collection" :
    {
      "rel" : {string},
      "href" : {string},
      ... links, queries, items, etc... 
      "permissions" : { integer value }
    }
}

2. Bundled in the User object

Permissions are stored in the user object and change based on the URL to provide the client with information on what this user can do at this particular state in the application.

{
  "collection" : {
    items: [{
      ... name, username, etc...

      "permissions" : { integer value }
    }]
  }
}

3. Beyond the scope

According to the draft specification:

The Collection+JSON hypermedia type is designed to support full read/write capability for simple lists.

I suspect that by providing a Collection+JSON response, it is assumed that all CRUD operations are available to the client and that the server will provide the appropriate response when a request is made.

5
  • 2
    If you just have a simple permission system that directly maps to the different HTTP verbs (POST, GET, PUT, DELETE), then you can indicate the permissible actions in the HTTP Allow header. Jul 29, 2014 at 15:50
  • Didn't think about that. That's an elegant solution.
    – Pete
    Jul 29, 2014 at 15:53
  • @BartvanIngenSchenau could you please put your comment as an answer ?
    – redben
    Oct 26, 2015 at 11:54
  • @redben: My comment is a bit short for an answer and I don't have the time to write a proper one. If you want to write a proper answer based on it, go ahead. Oct 26, 2015 at 12:18
  • Though short I think it is a perfectly valid answer.
    – redben
    Oct 26, 2015 at 12:21

1 Answer 1

2

As @Bart van Ingen Schenau said if your permissions can be mapped to http verbs, you could use the Allow header to indicate which operations are allowed on a resource.

But since you talked about the use case of deciding wether or not to render buttons (like edit, delete etc...), you'll find that the Allow header is not enough for collections. That is if you need to know wether an operation is allowed per item. A client could loop through the items in the collection and do an http OPTIONS request on each but...

The other option for collections is to add the allowed methods somewhere in your item objects. I tend to put them with the links (or _links if you're into HAL):

  GET / things
  Allow: GET, POST

  {
      comment: "Collection of things",
      items: [{
          name: "thing 1"
          links: {
              self: {
                  href: '/things/1',
                  allow: ['GET', 'PUT','DELETE']
              }
          }
      }, {
          name: "thing 2"
          links: {
              self: {
                  href: '/things/1',
                  allow: ['GET', 'PUT']
              }
          }
      }]
  }

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.