> A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations. [Failure here implies that clients are assuming a resource structure due to out-of band information, such as a domain-specific standard, which is the data-oriented equivalent to RPC's functional coupling].

I don't even know how I'd write a client against a server that arbitrarily changes endpoint URIs. I honestly don't see a benefit of RESTful if REST requires complete decoupling of the server and client. REST isn't SOA. There is no discovery API for REST. If I don't get to hardcode /api/vehicle/, then how else can I write a functional client?

As with a lot of things in REST, the answer lies...in your browser. How did you know how to answer that last comment? You clicked a link for it. Not everything about REST can be answered by "just look at your browser", but a lot of things can.

If you follow a link you don't care what the URL is. You never needed to type out "/reply" to use Hacker News, you don't need to do it to use an API. That's what the article is about.

The actual URL is unimportant, you just need to know what the link for "/api/vehicle" returns to do something useful with it. Like you knew that "/reply" would give you a form with a place to type out a reply.

> I don't even know how I'd write a client against a server that arbitrarily changes endpoint URIs.

The thing is, you don't have to. I can write one for you and you'll never need to write another one again. You could use it and just have to implement the part that matters to your application, the semantic of it. You wouldn't need to hardcode anything, or even handle URIs at all.

You could use it for Tesla's API, Twitter's, Facebook's, whatever. If they used links you could use the exact same client for anyone, just needing to re-write the logic part (like creating a post on Facebook, a tweet on Twitter, etc).

Problem is hardly anyone actually implements links so you can't do that. It sounds like utopia but it's just the product of extreme decoupling. It's not really any different than browsers.

Thanks for the post. I still don't completely follow your example of the client you could write for me. Can you recommend any articles that go into more detail on this with examples? The level of abstraction in Roy's article was difficult to follow.

It's not a simple thing, so don't worry. It took me a little while to understand and it wasn't without some head scratchers.

Best places to be are at discussion groups (api-craft, rest-discuss). Steve Klabnik has a good book on REST that explains it in more layman's term. Fielding's a PhD (REST was his thesis) so his writing is intended for an academic audience, it's indeed hard to follow without previous introduction.

I actually "understood" it on api-craft. The real-life examples it has are very helpful.