I had the same issue.
If you search specific places, the user must have access access to each of the places. Otherwise, it throws an error. We would much prefer it not search the inaccessible place(s), and continue searching the rest.
In my opinion, the current behavior (return a 403 if you ask for content from a place you are not allowed to access) is the correct answer:
- It is consistent with any other API call that tries to access the place or the content in it (they all return 403s).
- It is a clear indication that you explicitly asked for something you are not allowed to access (versus, say, a search that doesn't have any place criteria, where the system does silently filter out matches you are not allowed to see).
- It avoids the very misleading alternative of not letting the caller know they tried to do something that was disallowed.
Note that an API caller can easily tell whether they have access to a particular place by trying to access that itself (GET /api/core/v3/places/368954). If you're not allowed to do that, then the client application should not include that place in its filter criteria.
I disagree with your assertion that this creates consistency:
- The search API without any place specification uses entitlements to filter unauthorized places. This should do the same to be consistent.
- I fail to see the clarity of the 403 when the user actually DOES have access to some of the places?
- Return packets are great at returning additional information to applications, such as "unauthorized: /places/368954". HTTP return codes are inherently lousy at it, as this conversation demonstrates.
Your suggested work-around does provide an answer to getting an authorized list of places, at the cost of MANY more API calls. This makes for solutions that do not scale well.