restful url - REST API - filters, child entities or is leaking information really so bad? -
the basic problem
i have rest api. sake of example, let's have users, can members in number of groups, , both users , groups can own objects.
any user can filter objects various criteria:
/objects?color=green /objects?created=yesterday but members of given group can filter group ownership:
/objects?groupid=1 and actual user can filter user ownership:
/objects?userid=55 there 2 basic patterns - 1 make object child entity of group, such as:
/groups/4/objects/1 with 4 being group id , 1 being object id. other option having group , objects side-by-side:
/groups/4 and
/objects/1 making object child of group and/or user eliminate other filtering options - essentially, have 1 object multiple paths it.
the actual question
if want limit access regular user he/she can access objects directly owned him/her or groups he/she member of, work filter on collection - entity level?
if try:
/objects/9 but object owned group not member of, expect authorization error, while if object doesn't exist @ all, expect "not found" - this, however, leak information book's existence, , have retrieve object in order able determine whether or not user has right see it.
so came this:
/objects/9?groupid=4 or
/objects/9?userid=55 in this, can base initial decision on authorization on group id or user id, , try retrieve object additional restriction.
if user not member of group 4, can not authorized, , if book doesn't exist, can not found, meaning not object doesn't exist, object doesn't exist in group 4. answer more clear, , not have retrieve object first.
the alternative return authorization error regardless of whether due fact not authorized or due fact object doesn't exist. answer imprecise, put less of burden on caller.
another possibility map multiple paths:
/objects /groups/4/objects /users/9/objects /colors/green/objects this seems rather messy , violate principle of having single path single concept.
does have practical insight on this? reasons (apart ones mentioned) why 1 or other preferable?
if understand correct, every object linked (at least) 1 group or (at least) 1 user, don't have problem of having object without group or user.
if case don't see point in using filters not make sense in rest way , not give benefit client site.
so suggested use following:
/groups/$groupid/objects/$objectid and
/user/$userid/objects/$objectid now server should check if client authorized ("the user member of group" / "the current user") given $groupid xor $userid
- if not authorized: not check if object there. give not authorized error.
- if authorized: give standard response codes
i don't see benefit non authorized client information if resource available or not not important him, because cant access either way. , suggested result in information leak which result in security problem (but depending on api , information , usage).
now lets go through scenarios group calls:
user arnold (member of groups: 1,2,3) wants access existing object 7 of member group 3.
get /groups/3/objects/7
response: #200
user arnold (member of groups: 1,2,3) wants access non existing object 55 of member group 2.
get /groups/2/objects/55
response: #404
user arnold (member of groups: 1,2,3) wants access existing object 11 of non member group 5.
get /groups/5/objects/11
response: #401
user arnold (member of groups: 1,2,3) wants access non existing object 19 of non member group 5.
get /groups/5/objects/19
response: #401
and user objects:
user arnold wants access non existing object 56.
get /user/arnold/objects/56
response: #404
user arnold wants access existing object 13.
get /user/arnold/objects/13
response: #200
user arnold wants access jon's existing object 77.
get /user/jon/objects/77
response: #401
user arnold wants access jon's non existing object 88.
get /user/jon/objects/88
response: #401
as can see server responds #401 if client non authorzied. additional great give error message in body e.g. sorry, not authorized see content of user "jon" or sorry, not authorized see content of group "abyzx", client knows problem is.
this seems rather messy , violate principle of having single path single concept.
i don't see way different sources (1) (3) , so answers no problem have multiple paths or uris.
each resource in service suite have at least 1 uri identifying it.
it clients understand authorization process , them navigate through api.