Harry Pierson asks a great question in his post on REST (A REST Question).  I’ll summarize his excellent post this way: what makes something RESTful?  Is it the protocol or is it the constraints in the architectural style?

My take.

Rest is succeeding where SOAP has had a hard time.  Clearly, the REST folks are doing something right.  We want to bring some of that “right thinking” in to SOA initiatives. 

The thing is this: there is an interrelationship between the REST architectural style and the REST protocol and mechanisms.  In a sense, each has had some influence on the other.  But I’m going to take a stand and pick the ‘most important one:’

I believe that the REST IFaP is the high order bit.

In case you may not be a regular reader of my blog, an IFaP is a grouping of attributes (Identifier, Format, Protocol) that, when viewed as a unit, forms the basis for Middle Out Architecture.  Each of the successful Internet standards, from HTTP to SMTP, has an IFaP at the heart of it.  IFaP is the generalization that allows for adoption, and in this business, adoption is the key indicator of success.

The question that Harry asked was this: if we use the REST style but we drop HTTP, is it RESTful? 

No.

The HTTP request and response mechanism is part of the core IFaP for REST.  Therefore, if we want to maintain the adoption, and therefore, the success of REST, we cannot do it without using URI and HTTP.  It is not clear to me if the REST world is more aligned with JSON or XML for format, but it is clear that these are the top two standards.

My opinion, of course, is mine alone.