in Uncategorized

Resource Types

In his latest post, JJ also asks this question:

You simply don’t attach business logic to a resource instance (in general), you need a resource type for that, which is missing from the REST model (which in the first place was never designed for doing the kinds of things.

I think this is an important point, and that is why I think people should pay more attention to media types. Apart from identifying the type of the representation contained in a request or response, media types help clients and servers to fire off the right business logic to process information that they received over HTTP without actually parsing the message.

There is a concern among some that introducing new media type for every kind of information is a bad thing, but I disagree. HTTP is designed to be a visible application protocol, i.e., an intermediary should be able to execute arbitrary processing rules just by looking entity headers such as Content-Type, Content-Length, Content-Language etc. Using concrete media types keeps the interactions visible.

I do understand the concern with new media types. If different parties introduce new media types with overlapping semantics, it could lead to interop failures. But I don't think applications should restrict themselves to standard media types.

Weak media types, such as application/xml or application/octetstream, force intermediaries and other pieces of code to parse the message before deciding what to do with it. This can get expensive if such processing needs to happen across machine boundaries.

When I was working on SOAP web services, one of the problems we had to deal with was to parse the SOAP envelope before dispatching a message to the right branch of code. In our product, our code had to deal with different kinds of messages, and even when the dispatching was in-process, it turned to be hard to prevent various parts of code path to not parse the same message again and again, and we had to resort to some clever hacks. There was a possibility of using the SOAPAction header, but ironically, WS-I Basic Profile prescribes against that.

I have the same concern with the Atom Syndication Format as well, as a universal payload format for all kinds of representations.

Write a Comment

Comment

  1. Subbu:

    I think we should start 2009 by running an “actus fidei” and burn WS-I for ever. There is not a document that is more anti-SOA than WS-I Basic Profile.

    Couldn’t we use endpoints efficiently to avoid the kinds of problems you are talking about? (e.g. one end point per service and not one per ESB). Ultimately, stitching SO on top of OO or other primitive forms of computing languages is not going to help solve that problem.

    The other issue I see with overloading media types is that it seems that media types are the only possibility for a decent versioning strategy in REST and unfortunately the combinatorial aspect of overloading media types for different usages could result in an explosion of media types.

    • JJ:

      The other issue I see with overloading media types is that it seems that media types are the only possibility for a decent versioning strategy in REST and unfortunately the combinatorial aspect of overloading media types for different usages could result in an explosion of media types.

      Media types are indeed central to versioning. Unfortunately, most APIs out there rely on URIs for versioning, which does not work.

      However, I am not convinced that “explosion of media types” is a problem.