Roy Fielding Video

Stefan Tilkov links to Roy Fielding presentation video. It is about 30 minutes long & well worth being late for work over ;)

I wish I could go to ApacheCon to see the latest in person.

GData AtomPub Podcast

I just listened to The world of Google data APIs. It is 42 minutes long. I took notes.

Here is the agenda:

• What "Google data API" actually means (the parts and pieces)
• What Atom, Atom Publishing Protocol, and other tech behind GData are all about
• What GData adds to the mix on top of Atom and APP
• How Atom compares to RSS
• What are ETags? And how can they help me?
• Why REST, the style, was chosen for these APIs
• Where REST makes sense, and where it doesn't. Resource driven vs. RPC.
• What the first GData APIs were
• How the killer app of syncing data with Google Calendar
• How you actually use the APIs? What do they need to learn? What tools do we give them?
• Can you write APIs that implement the same GData APIs?

Notes: Atom is an IETF standard in case you didn't know. RSS isn't.

Google has been working with Atom for over 2 years.

AtomPub provides a basic REST API - Google thought this was a great starting point. Atom leaves query to the student. Google uses URLs to do this. You can have output sorted etc. Atom doesn't say anything about this.

ETags were unfortunately not implemented. They chose a version number in the URL so that multiple people can write to the same entry. Plan to implement ETags in the future.

Are ETags magic? No, a lot simpler than they sound. A little string that tells you the version of the entry. Just a great way of making caching work & making the web more efficient.

Chose Atom because of momentum. And sold on REST. Not SOAP because the web is based on REST. Much easier for devs to learn REST than SOAP. SOAP require tooling. REST is simply manipulating tables of entries.

What are disadvantages of REST? AtomPub is just an implementation of the REST style. Difficult to map certain types of operations to REST - translation API example: send text & send back a list of options & then feedback how to improve the translations. Document centric request / response that was never saved on the server. Just a straight RPC call. REST is about manipulating resources.

How about transactions? Each request is essentially transactional. REST not concerned with multi-resource transactions.

How do devs use? Can use curl if they want to - some do create apps with shell scripts and curl. Have a Java, .NET, PHP, Python, Objective C API. Contributed APIs: Lisp (Patrick!), Ruby, Flash in development. It's just XML over HTTP - it's NOT THAT HARD!!

Authentication - "Client Login" is pretty straight forward auth. URL for uname/passwd where you get a token back that is your identity. Authentication for Web Apps - "Auth Sub" used for "on behalf of" type stuff. You can grant access to other web sites. You control who has access to.

Can I use Google Auth? They are meant to be open standards. Google legal hasn't signed off yet, but licensing will be worked out soon.

What is this "Kinds" business? Entries get passed around a lot - kinds concept is Atom categories to tag each entry with a "kind". Just gives more semantic information to computers (clients).

AtomPub Google Interop Event? 12 devs from different orgs came. Great success. Google's basic AtomPub worked fine. Google custom auth scheme was more problematic. After that everything worked smoothly. A lot of the impls built around AtomPub introspection document - Google doesn't use them much. Will in the future.

Any GData / AtomPub tips? Google has a particular approach to designing APIs. AtomPub good at certain APIs. Things that map well - RPC not one of them. On occassion Atom Entry is just a pointer to the real data (e.g., photos). Prefer to put data in entry as much as possible. There is a lot of art/style/parsimony to it. You can achieve a lot with 1 feed with a lot of query parms. Have to review APIs & ensure that they have good clean concepts: this feed clearly includes these types of elements.

WADL? Haven't found the need for it.

Atom can be tough to get at first, but once you do it is amazingly simple & then applicable to many. Very good programmers who don't understand AtomPub gargen/language can. Concepts are very simple. Feeds, entries, links to other entries. Very simple mental model once you get it. All APIs make the same. Very powerful.

Google working with the IETF on improving Atom/AtomPub. Introduced batch model that increases efficiency a lot. Auth. Teams in Google are very ambitious - hope to make publically available as drafts that can become standards.

Some talk of JAY-SAHN (JSON).

REST Conversation

Benjamin Carlyle has a good post on simplifying the introduction to REST here.

I love the question/answer style blog post. I have to do that sometime.

REST dirty hands

Via Stefan Tilkov who quotes Sanjiva Weerawarana:

IMO the real underlying problem is that as long as programmers expect to write a class and flip a switch to get a service or one or more RESTful resources then we have nothing really but RPC masquerading as something else. Both resource and service advocates would be well-off in trying to move the developer community to get past the “class is all I need” stage. If REST is successful in getting developers to get their hands dirty more power to it.

I say this all the time. I wish more people would listen to me!

People get caught up in automation and false simplicity. And then they are trapped, but it is too late. And then they go off searching for the next "simple" thing that will damn them. Odd really.

Nice REST post

Joe Gregorio: RESTify DayTrader.

Why build a RESTful web service for DayTrader? Because I frequently hear that REST can't be applied to complex situations. I also want to use the example as motivation for talking about some of the idioms that are available to handle more extensive requirements.

WADL - Or Maybe Not

I have changed my mind on thinking that WADL Gateway Drug.

Dare Obasanjo has a great post on it. It pushed me over the edge.

If it was the only way to convince someone to not go the WS-* route, I'd go for it. But too much madness can result from it and it is just much simpler to avoid this for now anyway.

Here was the clincher for me from Dare's post:

Another word that is often abused in the SOAP/WS-* world is contract. When I think of a contract, I think of some lengthy document drafted by a lawyer that spells out in excruciating detail how two parties interact and what their responsibilities are. When a SOAP/WS-* developer uses the word contract and WSDL interchangeably, this seems incorrect because a WSDL is simply the XML version of OMG IDL. And an IDL is simply a list of API signatures. It doesn't describe expected message exchange patterns, required authentication methods, message traffic limits, quality of service guarantees, or even pre and post conditions for the various method calls. You usually find this information in the documentation and/or in the actual business contract one signed with the Web service provider. A WADL document for the REST Web service will not change this fact.

Is REST Winning?

Stefan Tilkov brings a more rounded view than I have been bringing in simply declaring victory. Really rather silly of me.

The other shoe drops - And then there was light.

Well, Burton Group delivers the knockout punch IMHO.

What a difference a year makes.

Welcome Anne Thomas Manes. Anne is wicked smart - that is a fact.

May 09, 2006: I'm one of the folks responsible for mixing the Kool-Aid. I presented at the W3C Workshop on Web Services (representing Sun). I participated in numerous standardization efforts at W3C, OASIS, WS-I, uddi.org, and JCP. I have a vested interest in making sure that WS-* succeeds.

May 30, 2007: If you're ready for REST I suggest you jump on board right away and get ahead of the curve," she said. "You'll have to train your developers in REST principles. You'll probably want to adopt one of the new frameworks or help build one yourself to help your developers implement RESTful applications. You definitely need to provide guidance to your people. What you want to do is work to the point where REST becomes the default for all your distributed applications."

I certainly disagree with her time lines, but am glad she has seen the light on REST.

I'm very excited about the post WS-* world. It is settled - to my delight, much sooner than I predicted. This only reinforces my feeling that we are at a major strategic inflection point.

Wow.

What's next?

Via Mark Baker who really does deserve a trophy or some such.

Update Fixed date.

XML Code Gen & Service Description Langauge

Stefan Tilkov talks about Runtime Interface Dependency.

. . . while my application code may be tolerant to at least some changes, the generated infrastructure code isn’t

+1 for WS-DuckTyping.

I realize that my WADL Gateway Drug logic is therefore fairly twisted given my own experience with the over dependence/brittleness that results from code gen. My idealist side agrees that it isn't necessary. My "I wanna see this happen" side appeals to it because the current state of the WS-EnterpriseProgrammer thinks in a service description language way. I just want to throw them a bone. I'm not sure this is wise or what.

There are some good comments in Stefan's Does REST Need a Service Description Language? post.

My favorite:

peter: I’m very interested in how a “typical” REST development process looks like (if such a thing exists). Up till now I have to stick to WS-* at work. How would a cross project interaction work in the REST world? What does the service provider project team give to the service consumer project team? Just a set of URIs? How do they implement the REST service clients? Manually, using CommonsHTTPClient with an XML Mapping framework of choice? Do I stress the toolsupport too much?

stefan: "Do I stress the toolsupport too much?"

Yes, I think you do — after all, do you hand over a WSDL without any accompanying documentation when you use WS-*? Chances are you provide the other team with some documentation, either inline or separate, that they have to read before using your service. A great way to document your resources is to return HTML when someone does a GET …

CommonsHttpClient is a good choice. Whether or not you need an XML binding framework is orthogonal.

peter: Yes, you’re right. WSDL is not enough as documentation for the service consumers. Usually we provide the complete client api :) Which was not the intention from the beginning. But most colleagues ask for example code in their preferred language and not an interface description. Then we come to the question why we used WSDL in the first place? There is one thing were it really works. I use soapUI a lot for testing. Point it to your SOAP Service, append “?wsdl” and let it generate a sample request.

I think that Mark Baker sums it up concisely:

Cut the cord already! RPC is dead. You’re not in Kansas anymore.

Google GData

If widespread use of REST & Atom at Google don't convince you that perhaps that WS-* stuff doesn't have such a bright future, then perhaps enthusiastic nodding from a prominent MSFT blogger will.

Take a good hard look at GData. It is well documented and comes with clients for everything besides Erlang.

Via Tim Bray

WADL Gateway Drug

Stefan Tilkov responds to Aristotle Pagaltzis who thinks REST doesn't need a service description language:

In principle, I agree; for pragmatic reasons, I believe efforts like WADL make sense, if only to have an answer to one of the most obvious questions for new REST converts :-)

+1 to that.

Take a gander at the spec. I tear up just looking at it. It is beautiful compared to WSDL - just beautiful.

I think that the risk with any service description language is that people take it too far and become overly dependent on it. Generating code from them tends to do this. But then again, code gen can be helpful. You just have to know when you have taken something too far and not be afraid to press the eject button to dumb it back down.

I think that REST client developers at the very least will want schema definitions of what to expect in request/response payloads. IMHO WADL does a good job of not taking things too far. As I said, compared to WSDL it is a thing of beauty. It is so simple when the only option is HTTP (i.e., compared to the absolute insanity of protocol agnosticism).

If you aren't going to use WADL, you are going to have to document the service in prose or some such. WADL at the very least seems to be a really concise way to document things.

Update Somebody should give Mark Baker a trophy or something. I still will take WADL any day over WSDL, but Mark is probably right. Still, I'll take baby steps if that is what it takes.

Update 07-JUN-2007 I have been convinced that a service definition language is not good idea right now.

REST JSR 311

Yay - should be interesting to see where this goes.

via Dan Diephouse.

Here are some other links: Marc Hadley example

Tim Bray

Steve Loughran begs them to keep it simple

Hopefully the expert group will resist the temptation to trick it out too much & will just keep it simple. I think there are benefits of doing this - will help spread the REST goodness if done correctly. Please oh please have a firm red line between message framing and message body (i.e., don't slow boil REST into insanity by making things "easy").

Good to see that some genuine REST experts are piling onto the expert group. Keep an eye on the big vendors. I'm sure the individuals are fine, but the people behind them who will start asking questions about how to "monetize" it probably are not. That is what got us into the WS-* mess. Standards as a gateway drug to pushing product is the root of all evil.

And we all know that sometimes people join standards committees to subvert them. I'm certainly not saying that this is the case, I'm just saying . . .

I'm crossing my fingers that this will lead to good things.