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:
- Key/Value
- Arrays
- Relations
- Logical Graph
- 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 ;-)
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.
I think the problem is that there's no protocol definition or standard of how RDF can be used to manage data with HTTP as your interface.
If we just write "RDF processing code" then we're back to a format vs. a data model problem, because while RDF specifies a data model, it doesn't provide a data management interpretation of that model. Should be possible of course, just hasn't really been done because RDF had a different design centre and assumptions. But without such a standard interpretation, everybody's processing code will behave differently (such as in the partial update case), and we're back to square one. The W3C (well, TBL, at least) seems to be very focused on the "read only" case for linked data, or else they'd be looking deeply at this (for RDF and beyond).
As for an alternative, well, there's limited hope there as well. Data models are like religions among technical folks; the relational model arguably has a strong formal foundation but it's currently fashionable to shit on it. So I'm not sure what can be done other than supporting islands of data interoperability that kinda-sorta look relational (e.g. OData - which btw, could support RDF I think).
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.
Hi Bill, sorry for the late publish, your comment was caught in the flood of spam.
First, I'm not sure why there's a problem with partial update formats. Even most services have had this capability: .NET SOAP web services that used ADO.NET DataSets had DiffGrams, and plenty of RMI/EJB interfaces have sent custom partially-filled serialized POJOs across the wire with a partial update flag. Why not try and standardize the practice, to help developers out?
Second, my point is that the vast majority of interfaces suck because they're not designed with a managed data mentality, they're just dumb data structures designed for (server) programmer convenience. User convenience is much more important when designing for interoperability at scale. Generally speaking, they would like their data to be as linkable, shareable, and manipulable as their web pages are. Serialized data structures like JSON and XML are easy, but are far from simple when integrating across sites -- because each website is different.
Look, I'm not utopian, people have to get their jobs done, of course, and today that means your own flavour of JSON or XML. But I think we can do something simpler and more productive than that.
Finally, I take a bit of umbrage to your final comment. Thinking too much? How do you suggest we improve things if we don't talk about them? Does the world really end with JSON and XML mashups? You may disagree with the approach I'm suggesting, but I'd prefer if we spoke about specific ways to improve interoperability, rather than "don't even try".