I'm creating a restful web service. As JPA I use Hibernate. I have such entities like Country, City, Store, Sale and others.
Is it a good idea to have URIs like this in terms of length and nesting: http://example.com/countries/{countryId}/cities/{cityId}/sales/{saleId}/article/{articleId} ?
Is there any rule of number of nestings? I mean the number of pairs "entity/{entityId}" ?
URIs are opaque. As far as HTTP and the RESTful principles behind it go, there's no difference between http://example.com/countries/{countryId}/cities/{cityId}/sales/{saleId}/article/{articleId}, http://example.net/sfdaikwjepfiaosnd and http://example.org/ followed by the URI-encoded contents of Finnegans Wake. Indeed it's perfectly possible for all three of those to be URIs for the same resource, perhaps with one permanently redirecting to the other.
So it's non-REST concerns that are most at work here.
One is that if you are at risk of going beyond practical size limits you will have problems.
Another is that entities containing lots of URIs will obviously be shorter if those URIs are small. It's not generally a big concern, but it does have a bit of an effect on network use if URIs are truly massive and every entity contains kilobyte upon kilobyte of such URIs.
Another is just how useful the modelling is: If calling code will never care about the country when it wants an article then your modelling isn't helping that calling code.
Related to that is the practicality of relative links in helping the HATEOS aspect of REST: If you are likely to often be able to just have article/2 as a relative link that is useful in the entity describing a sale, or a (potentially hard-coded) ../../ to get to the entity describing a sale from one describing an article then this is convenient. The question is are you making the most useful links the most convenient. For example, if it is far more common to go from country to city than country to anything else, then why have the /cities/ part to the path, and not just {countryid}/{cityid}?
This relative link matter can counter the question of large URIs causing large entities: If the majority of URIs in an entity are "close" to the resource the entity describes then the majority of URIs can be represented by very small relative URIs.
Another aspect is whether those IDs are human-reader-friendly. Is the ID for New York something like 193 or something like NewYork or New%20York or perhaps Nueva%20York? To a REST perspective those are all of equal value, but 193 gives shorter URIs with advantages noted above while the others are handier to deal with as a consuming developer or when debugging.
Nesting also affects this human-readable aspect. On the one hand lots of nesting can make each element within that simple to identify but on the other it can be confusing in itself to have too many sections in the path. For the most part though if the split is understandable then a human reader can filter out much of the URI and focus on the part they care about.
In all the only hard limit is that of the practical URI size limits, and beyond that there aren't so much strict rules as pros and cons to consider the trade-offs of in your design.
