What isn’t REST

Roy Fielding’s blog had an interesting post where he was musing about what was missing from some services that call themselves REST inappropriately.

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

I don’t like the idea of Fielding as a sort of tech priest who gets to bless or excommunicate this service or that from the REST flock. So this article was really good because he addresses some specific concerns based on clear principles.

I thought the last three were really important:

A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server)…. [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].

A REST API should never have “typed” resources that are significant to the client…. [ditto]

A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API)…. [Failure here implies that out-of-band information is driving interaction instead of hypertext.]

Everyone likes to focus on the “restricted verb” aspect of the Uniform Interface, or on URI definitions, but it sounds like that’s really missing the big point. The more important point is an extreme abstraction away from the way we drive our web services today.

That is, today we put a set of URLs on a web page somewhere and call that our service API. Then clients begin cut-and-pasting those URLs into config files, or else use string concatenation to build the specific URLs for the information and methods they need.

Fielding’s point here seems to be that the service makes no guarantees about anything except the initial entry URL. From that response, the client can get everything else it needs to drive application state.

(Well, “everything else” is an exaggeration — even if your representations are XML or JSON, you’re still relying on out-of-band information to understand the nature of the document you get.)

But I thought this was a nice, detailed article talking about what he’s thinking.

Advertisements

1 Comment

Filed under Uncategorized

One response to “What isn’t REST

  1. Pingback: Distributed Weekly 89 — Scott Banwart's Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s