Nick Gall

A member of the Gartner Blog Network

Nicholas Gall
VP Distinguished Analyst
14 years at Gartner
35 years IT industry

Nick Gall is a vice president in Gartner Research. As a founding member of Gartner’s Enterprise Planning and Architecture Strategies, Mr. Gall advises clients on enterprise strategies for interoperability, innovation and execution. Mr. Gall is a leading authority on middleware… Read Full Bio

Coverage Areas:

How Does REST Help Solve Data Semantics Problems?

by Nick Gall  |  October 2, 2008  |  3 Comments

Eric Roch recently blogged (Gartner on SOA vs. WOA) about my REST interview and he asked an excellent question: “So let’s look at the [REST] constraints, can someone please tell me which of these constraints solves data semantics problems?”

The answer is the uniform interface constraint (UIC), which you can also think of as the “generality constraint”. Since an interface is composed of identifiers, formats, and protocol operations, the (UIC) mandates that:

  1. Identifiers be as generic as possible
  2. Schemas be as generic as possible
  3. Protocol operations be as generic as possible

for the type of application being architected.

Everyone who’s looked at REST now seems to get the generic protocol operations part: GET, PUT, POST, DELETE, etc. And some are now getting the generic formats part: Atom Publishing Protocol, GData.

But very few are focusing on the generic identifiers part yet — at least in terms of explicitly RESTful thinking. The closest thing to generic identifier work in enterprises is master data rationalization. Gartner defines master data as consistent and uniform identifiers and attributes for key business entities used across many business processes (at least that’s the gist of our definition). To make the master data connection to REST explicit, “consistent and uniform” identifiers across many processes translates into generic identifiers, or if you prefer Roy’s terminology uniform identifiers.

So REST doesn’t so much solve the data semantics problem; rather, properly understood, REST’s UIC puts the data semantics problem, ie mandating uniform, generic semantics instead of ad hoc, specialized data semantics, front and center. REST is the only architectural style I know of that makes interface generalization the primary imperative. On the other hand,  WS-* implicitly or explicitly encourages interface specialization. Steve Vinoski has a great article on the evils of interface specialization: Serendipitous Reuse.

Hope that helps clarify.

3 Comments »

Category: WOA     Tags: ,

3 responses so far ↓

  • 1 Eric Roch   October 2, 2008 at 3:20 pm

    Nick,

    This speaks to the difficulty of creating generic interfaces and common business objects (e.g. schemas that can be used for many purposes). Generic interfaces and common business objects is is not a requirement for WS but should be a SOA best practice. This is hard to do with WS or REST. It’s really the data that’s hard to get right, the operations are not so hard.

    But, I don’t buy the argument that REST will get data formats and semantics right serendiptiously for IT systems. There are certinaly examples on the web where this has been successful – e.g. Google maps.

    But when you are trying to make a bunch of IT systems support a business process you cannot depend on serendipity. You have a time line and a bunch of vendors creating interfaces that have to work together. You can created generalized interfaces for REST or WS or JMS or other distributed systems. It just takes work and governance.

    I do think this is a very interesting concept for the WWW though with examples popping up all the time. I just have not seen it for ERP or CRM or other enterprise applications. If you have please cite a case study.

    Thanks
    Interesting topic!
    Eric Roch

    Here is another relevant article I wrote on the topic of enterprise canonicals.

    http://www.ebizq.net/topics/soa/features/7175.html

  • 2 Frank Hood   October 7, 2008 at 5:06 pm

    Nick,

    I’m dealing with an SOA project right now that may be interfacing with a REST project, so your discussion is timely for me.

    As an old database programmer (a long time ago…), the whole discussion reminds me of hierarchical databases vs. relational databases. People sort things in hierarchies for simplification and easy memory purposes. Think Linnaeus and his animal taxonomy.

    How does your artificial intelligence work best? With Google–just find me where these terms are referenced–allowing for spontaneous discovery of connections we didn’t know were there, but also tending to give us lots of irrelevant results? Or with Windows explorer file type hierarchies–working our way down an ever expanding tree of hopefully more and more relevant information, but potentially missing relevant connections that weren’t stored that way?

    Of course even Gmail which advocates the flattest of file systems allows for tagging to create taxonomies without hierarchies.

    My brain works well with hierarchies, (the I can only hold 5 things in my mind at once rule), but I love Google desktop to find the things that I forgot where I put them.

  • 3 Mike Bergman   October 10, 2008 at 10:57 am

    Hi Nick,

    Your view of these matters and WOA is absolutely spot on. Thus, it was surprising in your answer to the rhetorical title of your post that you did not also mention your earlier post (http://blogs.gartner.com/nick_gall/2008/09/19/linked-data-turning-stovepiped-data-into-a-web-of-data/) that also contains a key: linked data.

    To augment your first definition of WOA we would explain the formula for data semantics and interoperability as:

    WOA + Linked Data + context

    Controlled vocabularies or common semantics such as what comes from XBRL or our own UMBEL (http://www.umbel.org) project are the missing mortar in the equation to cement the linked data and REST bricks.

    Thanks, Mike