The contents of URL strings are not supposed to represent resources -- If a client of your "REST API" needs to concatenate strings together to form new URLs based on an out-of-band 'specification', YOU'RE DOING IT WRONG
Repeat after me: Hypertext. Is. The. Engine. Of. Application. State.
URL strings should be completely opaque -- you should be finding link to new resources in other resources, not constructing them yourself (query strings added to found resources are permitted).
The whole "meaningful URL" thing is a strong signal of False REST, and it infects the Rails ecosystem pervasively. REST has nothing to do with your oh-so-clever request routing rules.
One can build a service that has so-called "Rails-style meaningful URIs" that also returns hyperlinks to new resources. They aren't mutually exclusive.
That said, yes, everyone seems to forget about hypertext. I'm curious: if I'm building a REST-based JSON-formatted service, what's the convention for returning related URIs? Ex: if I return a Product resource andi want to have links to the products image, the owner's resource, edit this product, and so on, is there a standard way to return them in the JSON structure, or doesthis nor matter?
Can you explain more? It seems like you're saying that RESTful APIs should somehow be self-documenting, and that there should be no need for an API specification. I've never heard this argument before and would love to know more.
Repeat after me: Hypertext. Is. The. Engine. Of. Application. State.
URL strings should be completely opaque -- you should be finding link to new resources in other resources, not constructing them yourself (query strings added to found resources are permitted).
The whole "meaningful URL" thing is a strong signal of False REST, and it infects the Rails ecosystem pervasively. REST has nothing to do with your oh-so-clever request routing rules.