License 2 Code

Congratulations to Jerome and his team for the 1.0 release of Restlets. I’ve been using this for a couple months now and have quite enjoyed the framework. I re-engineered the server APIs on a software project I maintained to use Restlets instead of the proprietary interfaces I had developed. Very nice!

Restlet 1.0.0 released! « Noelios Consulting

Duncan Cragg just finished part two of the REST Dialogues. So, the stage has been set. You can get a resource by using HTTP GET at a URI and you can suggest a change to a resource by POSTing the updated version of the retrieved resource. We’ve got alot of power here and the next article will focus on Business Functions. Now we’re going to get to the heart of the issue.

At the same time, Pete Lacey has written a very funny faux-dialog titled “The S Stands for Simple“. I absolutely loved this article. I’ll bet that you’ll continue to think back to this article as your write your next SOAP-enabled service.

A few funny excerpts:

SOAP Guy: Sure thing. First, SOAP stands for Simple Object Access Protocol.

Dev: So it’s simple?

SG: Simple as Sunday, my friend.

…

SG: Sure thing. First there’s the SOAP envelope. It’s pretty simple. It’s just an XML document consisting of a header and a body. And in the body you make your RPC call.

Dev: So this is all about RPCs?

…

SG: No. SOAP doesn’t really use HTTP response codes.

Dev: So, when you said SOAP uses HTTP, what you meant to say is SOAP tunnels over HTTP.

SG: Well, tunnel is such an ugly word. We prefer to say SOAP is transport agnostic.

…

SG: Remote procedure calls! Serialized objects! Where did you get the impression that SOAP was about RPCs? SOAP is all about document-based message passing, my friend.

Dev: But you just said…

SG: Forget what I said. From here on in we pass around coarse-grained messages—you like that term, coarse-grained?. Messages that conform to an XML Schema. We call the new style Document/Literal and the old style RPC/Encoded.

…

SG: Sorry to hear that, buddy. On the bright side, nobody uses the Doc/Lit style anymore. In order to get transport independence back we’re all using wrapped-doc/lit now. Doesn’t that sound cool: wrapped-doc/lit?

It’s a good 5-min read, don’t pass up the opportunity.

White Spy has been bringing the REST content to l2c, so when someone recommended this imaginary interview with an eBay architect on REST vs. SOAP, I had to read through. Interesting treatment, great way to draw out the differences.

Suggest an interview you’d like to see at l2c and we’ll see if we can swing it.

“Now I know how to do SOA right”. Marketing slogan from a test-automation company. You see, since “SOA is a methodology and technique to deliver J2EE, .NET, XML Web Services, Web applications, and anything else that uses a network to provide users with information services” (emphasis added) and “Services are always-on and must work well when many users make requests all-at-once.” SOA is all about performance testing.

Now granted I’m a fan of performance testing, especially when its incorporated into the dev process using tools like JPerfUnit and JMeter, and not done as an afterthought late in the quality assurance cycle. And I’m a fan of the PushToTest model, which is to support the community and user of the open source TestMaker tool. So this post isn’t so much to slam PTT as much as it is to highlight an interesting example of the hype train that is SOA… Read more »

In my research on REST this last week, I’ve seen several comments noting confusion on whether to use PUT or POST. After reading several references (Elliotte Rusty Harold, Sacrificial Rabbit, and Mark Baker) , I loosely paraphrase the rule as:

Use PUT when you know the ID of the resource you are creating or modifying and the operation is idempotent. Use POST otherwise.

In other words, don’t bother with CRUD as an analogy. Instead think:
GET –> View Representation of Resource
PUT –> Create/Modify client-identified Resource
POST –> Create/Modify server-identified Resource
DELETE –> Delete Resource

Updated on 11/4 to add the idempotent piece above.

Stefan Tilkov illustrates a fundamental difference between REST and SOAP with two graphics. REST being resource-oriented and SOAP being service-oriented.

SOAP

REST

The SOAP illustration has fewer classes, but is more obscure because the methods are the services. The REST illustration has more classes, but the operations are more obvious. A counter-argument is that complex services are harder to represent in REST than SOAP. But that’s the point, the resource-oriented architecture has differing constraints due to differing design goals.

Reference: http://www.innoq.com/blog/st/2006/06/30/rest_vs_soap_oh_no_not_again.html

Elliotte Rusty Harold’s post titled, “Why Rest Failed” starts with an inflammatory title and goes on to assert that rest failed because clients (browsers) don’t support PUT and DELETE - two of the four verbs required for REST. He notes that clients can use the XMLHttpRequest object and that XForms supports these, but not forms in browsers. He’s right on these counts, but he fails to elaborate on his assertion that REST has failed.

Has REST failed? It’s used in the ATOM publishing API, there’s a Java framework (Restlet) to support REST (in it’s infancy), and I often hear it used as a counter-argument to SOA. At the same time, I’m not sure a “faithful” implementation of REST has succeeded to capturing developer’s hearts and minds (by faithful I mean based on the Fielding Dissertation).

Has REST failed? Maybe. But there is sufficient interest in the topic from the tech community to keep it alive. And maybe that’s enough.

I spent last night looking into Restlet; the brainchild of Jérôme Louvel. My first impression is that the code is solid and is a faithful implementation of Rest concepts on the Java platform. I’ve started integrating it into a project I’m working on and will report back as I learn more. So far, my biggest stumbling block isn’t the software, but instead learning how to architect software using only rest.

It appears that a major part of rest is transporting representations between the client and the server. For example, to update an attribute of a resource, the client PUTs the resource onto the server using the appropriate URL. The simplicity is compelling. But, I’m very concerned about pushing complexity onto the client as a consequence of this simplicity. Stay tuned.

The Semantic Web will feed the hungry and bring world peace. A trusted friend talked up the semantic web over three years ago. ‘We should learn all we can and be expert consultants when this thing blows big!’ I didn’t invest much time, and I think its fair to say it hasn’t blown big. Now there may be a number of reasons why this hasn’t come to pass.

Back then, and still now - I had one major concern. The semantic web seems highly dependent on disparate groups with competitive advantage at stake coming to together around a standard, unified ‘knowledge’ model for a given domain. That’s not a technical problem, and yet seems very problematic in this day and age.

I was glad to hear Soyring’s keynote, where he described how IBM has targeted 17 strategic industries (two examples - shipping and payment systems) for system development. There was a hint that one part of this is working out a domain/data model standard. That was encouraging. But I struggle to find other reasons to believe the issue can be resolved in many business domains.

Amazon currently has three general purpose, developer focused web services: S3, EC2, and SQS. S3 stands for Simple Storage Service - and it is just that. Think of it as a large hash bucket for files. EC2 stands for Elastic Compute Cloud and can be considered virtual computing instances that can be programmatically created and destroyed. Lastly, SQS stands for Simple Queue Service and is a standard queue which is a standard FIFO queue which includes a 256K message body.

Amazon S3 is a very compelling web service Read more »