| > Sub resources sure but I'm not talking about sub resources because sub resources are dead easy. This is more of a "oh we should also display resource X, Y and Z in these different spots". The profile page is the resource (or a representation of the resource) identified by the URL (Uniform Resource Locator) used to access the profile page. This is true, pretty much by definition. Whatever is designed as part of that page, and is also a resource, is a subresource. > If you want to be really "RESTful", TYPICALLY (and I say typically because I think every developer has a different definition of REST, lol), your URLs only align to resources so joining resources means multiple calls. URLs align to resources in that the fact that a URL is used to access something defines it as a resource. There is nothing in REST which defines resources as only the orthogonal entities in a data mode (e.g., the loose equivalent of entities in the base tables of a relational DB model.) You certainly in many cases, for maximum flexibility, want your resources to include those kinds of things, but there is no reason -- at least none that has anything to do with REST -- for them to be limited to them. |
No that's not true at all. Your API design should not influence the user experience but the other way around and you're unlikely to change models should you have more optimal ways to presenting things.
On paper? Sure but I've never seen anything able to be split so nicely as you describe.