I have a general question about token handling precidence in the Rest
api server. It appears that some of the information encoded into the
rest urls is also in the token. When getting a url like this for app
data /appdata/{uid}/@self/{aid} you'd normally think that putting
somehting into {uid} and {aid}, userid and appid would affect the
query on the backend data, but if the contents of the token override
anything in the url, you're basically turning the appdata service into
an rpc endpoint called 'getAppDataForUser' and then passing in a
token. So what's the point of the rest service here?Is the rule that the url semantics are there for when oauth is used? Seems like these values are also intended to be encoded in a custom oauth header. So what's the deal here? Should the url drive the query composition and be verified by the token and throw an error if the two don't match? Should the server ignore the elements in the url favoring the token? thanks. davep
