I am talking about an architecture which only has services and messages, so where are the resources?
Aha! If that ain’t the $10,000 question … So, here’s my smart-ass 2c response;
Show me a message(*) and I’ll show you a representation of the state of some resource.
(*) a ProcessMessage message, aka a document.
In a really awesome essay (sorry for the delay, I was on vacation), Savas ponders, among other things, what it would mean to be a RESTafarian. It seems the one thing holding him back from being a card carrying member of the club though, is that the whole idea of binding application semantics to a protocol seems sorta silly to him. Well, I don’t believe it is, but fortunately, what you believe about that subject matters not to your eligibility for membership. This is because REST, as an architectural style, says nothing about how any particular architecture is implemented. “All” it does is constrain your architectural elements.
So, if your architecture has uniform connector semantics (even if there’s only a single one called “processThis”), and if your architecture has a single data element which identifies resources which act as message endpoints, and it uses fully self-descriptive messages, et cetera …, then your architecture is RESTful, like it or not.
Savas, your card’s in the mail. 8-)
P.S. it hurts to type so don’t expect speedy email or blog replies – a side effect of skewering your hand with a broken wine glass stem.
According to Radovan anyhow 8-)
Everyone programs in something different, so let’s just do protocol-based integration, where we will just agree on the format of the messages we are going to exchange over the wire.
I think this is the thing some ‘REST fundamentalists’ are still missing…
No, I think we get that. Or at least we get that it’s a critical part of the solution. This is why HTTP 1.1 is as well specified as it is (not that it doesn’t have issues, of course). The problem is that the format is only one part of the solution. The other part are the semantics of the messages, something that HTTP also specifies, but SOAP doesn’t … not that it should though, as it can always inherit them from the underlying protocol.
Right from the spec, we have this example of an EPR;
<wsa:EndpointReference xmlns:wsa="..." xmlns:fabrikam="...">
<wsa:Address>http://www.fabrikam123.example/acct</wsa:Address>
<wsa:ReferenceProperties>
<fabrikam:CustomerKey>123456789</fabrikam:CustomerKey>
</wsa:ReferenceProperties>
<wsa:ReferenceParameters>
<fabrikam:ShoppingCart>ABCDEFG</fabrikam:ShoppingCart>
</wsa:ReferenceParameters>
</wsa:EndpointReference>
Somebody please tell me why on earth that isn’t a URI? You know, something like;
http://www.fabrikam123.example/acct/123456789?ShoppingCart=ABCDEFG
Note to self; avoid using an HTTP header named “Status” in Webware, since apparently it’s reserved for holding the in-memory equivalent of the response code.
Ack.
What’s the best Python Web app framework, or should I just go back to Jython and javax.servlet?
One of the nice things about being a critic of the current approach to Web services, is that the infighting amoungst the players had a chilling effect on standardization efforts, which made my job – of keeping the W3C as free from this stuff as possible – easier. Unfortunately, today, everybody seems to have come together for the worst spec of them all; WS-Addressing is now a W3C submission.
SOAP, I liked very much, just not how people were/are using it.
WSDL, I didn’t like because of the bad practice it encouraged, but I felt that it might have a role to play.
But this monstrosity actively causes harm by not using URIs as EPRs. That part of the spec has no redeeming qualities, except that it represents an attempt on behalf of the authors to Do The Right Thing regarding addressing (i.e. standardize it). Unfortunately, those authors fail to recognize that we’ve already got a perfectly good identification spec.
Update; P.S. yes, I understand than an EPR has a mandatory wsa:Address, but that doesn’t change anything, as any identifying information in the SOAP envelope is necessarily in conflict with the HTTP Request-URI. One endpoint per message, please.
Sean highlights Reinout van Rees’s Zen moment
Awesome, another recruit!
I just want to add that I think it’s important to recognize that “getting it” requires a Zen moment. For everybody I know who came from a CORBA/DCOM-like distributed systems background, but now understands the Web, serious mental model rewiring occurred. If you haven’t had that rewiring, you don’t (yet) get the Web.