I'd say it depends on your audience.
No-dev
If your audience is not a developer's one, I'd go with the following way:
Let's say you return JSON for the sake of the example.
GET /cats HTTP/1.1
{
"cats": [
"Can I haz cheeseburger",
"If it fits, I sits",
"It's caturday!"
],
"permissions": {
"level": "free",
"information": "You have access to 3 cats. Upgrade to ... to get 10 cats!"
}
}
Or something similar.
It is informative for the user to know what the status of his account is, and it allows you to put whatever information you want, such as a marketing message. The most important point of this way is to give some easy visibility to your users of their current account.
Dev
However, if your audience is purely developers, then I'd say: go with the full HTTP compliant way. To store the metadata, you use HTTP headers.
Here is an example:
GET /cats HTTP/1.1
X-Account: anonymous
X-Account-Possible-Upgrades: 2
X-Account-Limit: 3
Then, provide a clear documentation of what these headers mean. Most developers will go straight for the documentation when they'll see these custom headers, especially if they're seeing a limit. You can go even further and show the link in the headers. Or you can show a link to the pricing page.
X-Account-Doc: http://your/doc
But then again, many developers don't know how HTTP works.
So it's your call
One is more correct, the other is more accessible.
Misc
Some other miscellaneous stuff related to your question:
According to URI standard the path should contain the hierarchical components and the query should contain the non-hierarchical components of the URI. But it can be subjective what is hierarchical and what non-hierarchical.
By developing a REST client these URLs mean nothing, because they follow hyperlinks and check link relations or other additional meta-data. (aka uniform interface / HATEOAS constraint)
If you cannot cache one of them, then you should choose the other one. Note: you always have to send cache headers. (aka cache constraint)
Best Answer
If your primary concern is preventing user X from accessing a resource A that's unique to user Y, then per-user ids don't solve this. What you really need is authentication, i.e. a secure way of verifying that a request for resource A is actually being made by user Y, not just some other user pretending to by Y.
If you don't have authentication, then per-user ids are merely security through obscurity. As soon as user X finds out what user Y's magic id number for resource A is, he can get resource A. If you do have authentication, then per-user ids are unnecessary, as your server can simply refuse to send resource A to anyone not authenticated as user Y.
The only time per-user ids would help is if the id itself is secret information, or indirectly exposes secret information. I can't really think of a scenario where this would actually be the case, but just to be safe I would generate GUIDs rather than incrementing a sequence number, since the sequence number reveals a little information (the order the resources were created in) while a properly-generated GUID reveals essentially nothing.
tl;dr I don't know of any reason why a per-user id would be beneficial, unless for some inexplicable reason you are unable to implement proper authentication or GUID generation.