REST API - use endpoint properties in authorization model?

Question

Is it a good practice to give permission to access endpoint?

For example

POST /permissions {method: "GET", resource: {href: "/users/*"}}
-> 201 {href: "/permissions/12345", id: 12345}

POST /roles/123/rolePermissions {permission: {id: 12345}}

and after this check the permission with the given pattern...

For example if I want to give permission to a friend to edit one of my articles, I can do the following:

GET /users/13/userPermissions
-> 200 {items: [{id: 99, shares: [], permission: {id: 1234, method: "PUT", resource: {href: "/article/1"}}}, ...]}

The client prints a fancy table with my custom permissions, now I can choose the permission 1234, and share it with my friend:

POST /userPermissions/99/shares {user: {id: 15}}
-> 201 {id: 111111}
-> new permission to "DELETE /userPermissions/99/shares/111111" is created and given to me (13)
-> permission to "PUT /article/1" given to my friend (15)

and after that I can delete it too

DELETE /userPermissions/99/shares/11111
-> permission to "PUT /article/1" revoked from my friend (15)
-> permission to "DELETE /userPermissions/99/shares/111111" revoked from me (13) and deleted

If this approach is not okay to store and check permissions, then what are the best practices?

inf3rno inf3rno · Accepted Answer · 2013-09-05T15:21:31

No, it is not. REST is just one type of delivery. You can have other deliveries, like SOAP, plain HTML web application, flash, java, and so on... So the authorization logic must be independent from them, and it should be part of the business logic, or it should be between the business logic and the deliveries.

REST API - use endpoint properties in authorization model?

1 Answers