AsynchronousBlog

In response to Dave’s update…

Responding to the RDF bits, I guess RDF/XML makes what you’re trying to express a bit more verbose, but it’s hard to call it difficult. It’d end up being…

John Hughes

…with ‘director’ as an rdf:type, and ‘name’ being the property/relation to the subject “12345.html”; or, in Turtle/N3…

<12345.html> a :director; :name “John Hughes”.

I’d recently worked out a different XML serialization — http://asynchronous.org/rx/ — for RDF that is a little more concise for data that’s mostly properties, and not so much about rdf:types. It also does not allow mixed-content, but it doesn’t require node-typing and thus element-striping; it would allow you to say…

John Hughes

… though that would result in the Turtle…

<12345.html> :director “John Hughes”.

Frankly, I like the version with “name” involved better, but it’s your data-model. :)

---

In any case, I see a bit more how this is specifically about REST, but I’d still argue that it’s more about change-handling in coarse-grained API design. If in a [local] procedural approach you may have…

Film.setName( String newName ); Film.setYear( int newYear );

… the argument goes that in a remote-procedural environment you should really, and only, just have …

updateFilm( Film newFilmData );

… to cut down on network round-trips, update overhead, synchronization/coherency concerns, &c.

So there is an interesting issue about how much of a representation — either the whole representation or just the changed aspects — need to be given back to the server. I guess it’s really a function of the server’s capabilities, as well as an assessment of the client’s capabilities, as well as what’s reasonable for the application/API.

Back to a “RESTful” worldview, one way to go is simply say “PUT back the whole representation”, which as you’re saying can be weird. Reasonably, the server may ignore [either silently or loudly] changes to some fields. An optimization of this may be to used something like RFC3229 to be more … um … optimal.

Another way to go would be to put something inline in the representation — either a form or indiciation that a certain convention is supported — that effectively says to the client “hey, you only need to send changed fields on update” or “here are the change-allowed fields” or something.

I’d consider these both RESTful, since both are talking about a constrained interface, placing the semantics in the media-type and document content, and using hypermedia as the engine of application state. The former certainly implies more server- and client-side smarts, and the latter is certainly what the web does. I guess if I were trying to be pedantic, I would call the later more RESTful, since the server is directing the client about how to proceed …

… but this is also the point I start to get into trouble about RESTful API design. In traditional RPC/RMI environments, the client is built with a specific understanding and knowledge of the API space. In the web, a human sits just past the client-side UserAgent, and interprets the generic HTML and forms that come back. I believe there is an intersection of those two, but I’m having trouble finding it.