Time for REST is over

| 4 Comments | No TrackBacks

Just read William's Partial resource update, one more time, which is another kick at the partial resource update can.

The problem is that few web services or RESTful hypermedia describe a data model. Representations themselves don't often describe a data model, they describe a format. This is the same problem as WS-RT, in that they're trying to describe updates to a format (XML), not a data model.

In Atom, this doesn't matter, as it kicks the responsibility to the entry.
In HTML, this doesn't matter, as the machinery of browser & server only needs the format for interoperability.

In systems-to-systems communication, this matters a whole lot, as you're coupling your expectations differently with every media type.

A data model is foundational, it describes the mathematical basis for how data is managed. Examples (for better or worse) include:

  1. Key/Value

  2. Arrays

  3. Relations

  4. Logical Graph

  5. Inverted List

OData describes an implicit data model, based on relations. RDF and OWL describe graph data models with an explicit theoretic foundation that makes them more powerful than Relations.

"Your New JSON Service" probably has a data model, but I bet it's unpublished, and in your head. And even if you did publish it, it probably is different from "this other guy's JSON Service".

What does all of this mean? I think it means that there's two big pieces of work to be done to help evolve RESTful web services to better interoperability:

(a) a data model that covers 80% of common use cases and can be formatted with JSON and XML. This needs to be a closed-world model, like most databases, and thus I don't think RDF qualifies.

(b) a media type that covers 80% of common use cases to describe a resource's lifecycle and state transitions -- in other words, to make POSTs self-descriptive in hypermedia. Because the world of computing isn't just about updating data, it's about abstractions.

It is passe' to perform SQL updates directly from your GUI. It's just as passe' to expect every RESTful hypermedia API to just behave like a database entity. So, we need something in between, something that gives POST meaning to systems. POST is the method which powers most of what we DO (vs. read) on the Web anyway. This "roll your own media type" trend works for simple situations, but really isn't sustainable in the long run, in my opinion.

p.s. yes, that "Part 2" of building a hypermedia agent article is coming ;-)

No TrackBacks

TrackBack URL: http://www.stucharlton.com/blog/mt-tb.cgi/149


I don't think the open worldness of RDF matters here; after all, most RDF processing code doesn't pay any attention to it (OWA), and it only really matters if you want to do spec-legal reasoning on the RDF -- which seems out of scope here.

We're supposed to be writing interfaces here, not databases. The vast majority of systems are going to take some JSON or XML format and convert it to transformation on a relational DB. This is why I can't stand things like "partial update formats" and even the PATCH command. I also don't get the uber-format argument you state here. How will it make things any better? A resource is not a file, or a data store, its a representation and interface to your system. I think you all think too much and lose sight of why people are initially attracted to REST. Dressing up your data in some sexy RDF, Atom, or whatever format is not my idea of keeping it simple.

Leave a comment

About this Entry

This page contains a single entry by Stu published on November 12, 2010 7:05 AM.

Put on your Thinking CAP was the previous entry in this blog.

WS-REST 2011 Workshop Call for Papers is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

About Me
(C) 2003-2011 Stuart Charlton

Blogroll on Bloglines

Disclaimer: All opinions expressed in this blog are my own, and are not necessarily shared by my employer or any other organization I am affiliated with.