The Multiple Meanings of Batch

Subbu has posted on the multiple meanings of BATCH. I do think it’s necessary to make this distinction.

I do think the use case of GET’ing a “batch” of resources and then only doing one type of write operation(PUT, POST or DELETE) is missing. I don’t consider this a PATCH, I think you use the method of choice i.e. PUT, POST or DELETE.


Arsenal Lets One Get Away

The Gunner’s missed a great opportunity tonight at the Emirates and now they face an uphill battle at the San Siro in a fortnight. It’s going to be very challenging for them to go in there and get a win. This is what happens when you fail to win your group when you’re the best team in the group.

In my opinion, it was an “above average” performance in which Arsenal generated a lot of movement in the midfield but struggled in the final third to generate very good scoring chances. Flamini had a great game in the middle of park as he practically shut down Kaka all game long. He’s definitely my man of the match. Adebayor had good movement upfront but his ball control let him down too many times. I still don’t get why Arsenal doesn’t take more shots at goal. It almost seemed like they wanted to work the ball into AC Milan’s net on a couple occasions where shooting may have been a better option. For Arsenal to move on, they are going play out of their minds.

Let’s see what the San Siro has in store for “The Arsenal”.

JSON or XML as hypermedia

For starters, I’ll propose that web services need to offer up multiple representations for a resource be it XHTML, RDF, Atom, XML or JSON, simply because you’ll run into someone who just lives and dies by a certain format.

Having said the above and now being at the point where I need to make a decision as to what format to use for my web services and being that my clients are generally non-browser (I rarely see REST discussed outside the context of browser front-ends, some additional posts on this would be great), XHTML is really not that appealing (even though it could work). Atom doesn’t seem to be a natural fit. This leaves me with deciding between XML or JSON.

I’ve used XML (and XSD) extensively in the past, so I really felt obliged to use this a my primary representation format. However, I began to objectively look at how I’ve used XML in the past and apart for validating using XSD, I can’t really say that I’ve used the document processing features and libraries (XPATH, XSLT etc) extensively i.e. I rarely treat my XML documents as “documents”. In fact, I use XML primarily for pure data transfer.

How do I know this? My code almost always, takes the incoming XML document and serializes it to an object that I can work with, finishes the business process, serializes the result of the process as XML and sends it back to the client. XML has been my ultimate data transfer format – and it has worked pretty well. However, JSON can work just as well (if not better) in such situations and ends up being closer to my problem domain.

I am not aware of a formalized way of specifying hypermedia (links) in JSON. If someone is aware of one, please share. But what I’ve chosen to do is mimic what you find in Atom with “link” metadata element.

I choose JSON (today).

Hypermedia As The Engine Of Application State

It’s been a while since I’ve blogged about anything – way too busy or maybe just not dedicated enough.

In the meantime, Nigeria lost in QF to Ghana, Arsenal is on top of the Premiership, the Patriots lost, Pau is in L.A., McCain has practically won the GOP ticket and I’ve been developing a REST-based system using Microsoft’s WCF technology. I’ll have to post on my WCF experiences later.

However, during this exercise, its become very clear to me that hypermedia and application state are probably the two most important things in a RESTful system. How an application transitions from one state to the next via links (essentially what you do with your browser) is primarily what a designer should be focused on. The resources, URIs etc just begin to fall into place after that. The representation you use becomes less of an issue as one realizes that in order to keep the engine running, links must be provided.

Most SOAP-based web services cannot provide an application with links on what to do next. This may be okay if there are no more state transitions, but how often is this really the case? To me, this is the most important difference between building a MESTian web service or a RESTian web service. If your RESTful web service, does not leverage hypermedia, its not that much better than a MESTian web service.

Equally as important is the discipline to avoid URI construction in clients besides basic GETs. Doing this will lead to much pain and suffering.

Here is another good article by Peter Williams that addresses this.