[BinaryIdiot]

> There's nothing RESTful about making more HTTP calls. There's no reason that there can't be representations of a resource in a RESTful API that happen to include, in the representation rather than by reference, representations of subresources.

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".

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.

Google has an interesting solution for batch HTTP requests that could kinda be used in a way to batch RESTful requests but it's not the most intuitive. https://developers.google.com/drive/web/batch

[nulltype]

I think some of these problems are solved by HTTP/2 multiplexing.

My experience at least with using REST for APIs seems to agree with yours. REST APIs, like traditional OO programming, seem to only help in a small number of situations. I've seen some really complicated things in the name of "RESTful"ness, like crazy Accept headers for different versions of the API. And like you pointed out, each developer seems to have their own idea of what REST means.

Approaching the API design from the other direction seems better. What is HTTP offering you that is better than just using a socket? It's got a request/response thing with message framing, some handy out-of-band stuff with the headers, there's HTTPS support, it works directly with browsers, and sometimes you can even get it to work through a proxy. HTTP requests are also supported pretty easily (more easily than socket stuff maybe) in most languages.

Then, using features from HTTP where they make sense can be nice (maybe some of the status codes or ETags are useful?), but throwing the whole nebulous REST framework in there without considering how well it matches the problem or how it adds to the complexity of the solution is not a good idea.

[dragonwriter]

> 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.

[BinaryIdiot]

> 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.

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.