Does 'api/SomeEntity/ForOtherEntity/{otherEntityId}' break REST?

Question

Using the example of facebook users having a collection of photos, if I'm designing a RESTful API for the photos, these will have GET/POST/PUT/DELETE endpoints for the photos themselves, is it breaking REST or a design patterns to have a get by user id? e.g.

GET Photos/ //gets all photos
GET Photos/12345 //gets photos with photo.id=12345
GET Photos/ForUser/27 //gets photos for user with user.id=27

Does this break the design principle of REST APIs? More importantly, what would be the practical negative aspects of adding methods that relate to different entities than the subject of the API?

Answer 1

No, your URLs does not break any principles of REST - for the simple reason that REST is not concerned about URL structures.

I would recommend reading one or two of the "REST" books mentioned at http://www.infoq.com/articles/rest-reading-list to get started on REST.

If you further more read through the original definition on REST then you will find nothing about URL structures (see for instance http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm).

Answer 2

According to Rest Standards parent entity should come first in URI followed by it identifier and then any resource inside that entity. You can refer to Rest API Design modelling article by Thoughtworks

Following are correct URI as per rest standard.

GET Photos/ //gets all photos
GET Photo/12345 //gets photos with photo.id=12345
GET User/27/Photos //gets photos for user with user.id=27