> I'd argue that in REST it would be desirable that resource representations do do that (provide [...] the direct locations of any embedded subentities that are separate addressable).
You could actually go a step further - if you're using "Hypertext as the engine of application state" (HATEOAS), URIs for the locations of direct subentities need to be there, if the client is expected to be able to make those state transitions, for the API to be "fully RESTful". (Though, I'd personally agree with the article that features like discoverability and content negotiation are secondary to those you get from idempotence/properly using HTTP methods, and feel they should be considered bonus features, rather than strict requirements)
> You could actually go a step further - if you're using "Hypertext as the engine of application state" (HATEOAS), URIs for the locations of direct subentities need to be there, if the client is expected to be able to make those state transitions, for the API to be "fully RESTful".
Sure, I'd agree with that.
> Though, I'd personally agree with the article that features like discoverability and content negotiation are secondary to those you get from idempotence/properly using HTTP methods, and feel they should be considered bonus features, rather than strict requirements)
I think properly using HTTP is sufficient for calling something an HTTP API, but HATEOAS is necessary for calling it (accurately, at least) a REST API.
There's too much "REST is a popular idea, so lets call out API REST even we think is good for our use case, even if its not REST".
All APIs don't need to be REST APIs, but APIs that call themselves REST APIs should actually be REST APIs, and not just HTTP APIs.
You could actually go a step further - if you're using "Hypertext as the engine of application state" (HATEOAS), URIs for the locations of direct subentities need to be there, if the client is expected to be able to make those state transitions, for the API to be "fully RESTful". (Though, I'd personally agree with the article that features like discoverability and content negotiation are secondary to those you get from idempotence/properly using HTTP methods, and feel they should be considered bonus features, rather than strict requirements)