Twitter upon first glance, is daft. If you were to click on that link right now you would see what appears to be disjoint messages from everyone answering the question "what are you doing right now?". If you are like me, that is probably the most inane thing EVAR, and you'll close that tab and be done with it. My god! It's worse then blogging! That being said, visiting the twitter main page is hardly a reasonable introduction to twitter at all.

In fact, I would say the best way to get introduced to twitter is to ignore the front page and join. Assuming you are one of my friends, add me and then you'll start seeing what it is all about. What everyone is doing is so absolutely unimportant to my own life that I just don't care. However, what my friend are doing can have some really serious impact to inspire, motivate and connect. Here are a few examples:

• mux twitters constantly about the time he spends in the studio, consequently I am sticking to my at-least an hour a week personal promise of studio time (but I've really spent 3 or 4) This is really quite a feat given how little time I have been in the studio before then.
• I've twittered about a track that I am listening to obsessively, which prompted Stormchild to go download and listen, and we've both been tarding over it ever sense.
• It's become a J-Pop support group between people who's identity will be protected.
• General questions can be posted via twitters, and answered in a matter of hours

Essentially Twitter is like broadcast IM. There have been plenty of times that I have wanted to broadcast something to my friends, but didn't feel it is worthwhile to actually bug someone with a message; in this cause I would just twitter it up.

but not only that, it tends to tighten ones social circle. I feel that I am getting tighter with my twitter friends, by virtue of this alternate communication channel.

The important thing about twitter isn't "What are you doing?" but rather, "What do you think is important about what you are doing?" I don't twitter that I am on the bus. I twitter about what I think is important, like The Key to a good morning routine or when discovering/creating A new turn of phrase. I think that is something special, these glimpses into what people feel is important enough in their daily lives.

All this being said, I am very glad that I got into the Status Message thing through twitter (and with the cool twitter group that I have) instead of through Facebook.

On top of it all, Twitter is RESTful. REST is cool.

In my mounds of spare time (ha ha ha) I've been playing with Scheme again. I've been seriously trying scheme-48 (very nice and elegant) and Gambit (very usable). Right now I am in the midst of working with a webserver written entirely out of scheme, to play with my own web-application ideas. I want to focus on the idea of a webserver that deals strictly in resources, something very RESTful and elegant.

We'll see how it goes.

Anyway, I needed a cygwin compatible speedy build, and because I couldn't do one at home, I thought, why not at work? And if I am going this far, why not post it so that someone else can use it?

Here ya go: gambit v4.0 beta 17 with --enable-single-host

Technorati has a new service up, the Contacts Feed Service, essentially this simple service will scrap a website, and pull out any hCards, and turn them into vCards for address book insertion. Very cool. How do you use such a service? Easy! Just pass it the URL of the screen to scrape, and away you go. For instance, to get my address book entry, just click on this link:

http://feeds.technorati.com/contacts/http://portfolio.jonnay.net/contact/

It is a very simple web service. A simple GET request returns a piece of data. It by virtue of its simplicity is RESTful. This is what REST web services really are all about.

I found a neat little surprise the other day. It appears that the Mozilla extension auto update feature is RESTful; I found this out through the use of LiveHTTPHeaders. Whenever you have an extension like Spellbound or Firebug, Firefox will call home to a server, and perform a version check, comparing your version with the latest version it has. It is not 100% RESTful, the biggest problem being that there is an end-point style URI (https://addons.mozilla.org/update/VersionCheck.php) with a query string (reqVersion=1&id=firebug@software.joehewitt.com...) ideally, the uri would be something like /update/VersionCheck.php/1/firebug.software.joehewitt.com/... giving each unique identifier its own space on the URI.

Beyond that however, it is very good use of HTTP, all the information needed is encapsulated in the request and is stateless. Really this shows that a lot of simple web services are either inherently RESTful, or are just a hop skip and jump away from being a true rest webservice.

This is the important thing about REST webservices. It is not that you need to conform to a "REST Standard", but instead you conform to the HTTP spec and end up, by design, following at least some of the REST constraints.

For reference (and the truly geeky) , here is the request and response:

Request

https://addons.mozilla.org/update/VersionCheck.php?reqVersion=1&id=firebug@software.joehewitt.com&version=0.4&maxAppVersion=3.0&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=1.5.0.3&appOS=WINNT&appABI=x86-msvc

GET /update/VersionCheck.php?reqVersion=1&id=firebug@software.joehewitt.com&version=0.4&maxAppVersion=3.0&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=1.5.0.3&appOS=WINNT&appABI=x86-msvc HTTP/1.1
Host: addons.mozilla.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en,en-us;q=0.7,ja;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cache-Control: no-cache

Response

HTTP/1.x 200 OK
Content-Length: 939
Connection: close
Content-Type: text/xml; charset=utf-8

<?xml version="1.0"?>
<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:em="http://www.mozilla.org/2004/em-rdf#">

<RDF:Description about="urn:mozilla:extension:firebug@software.joehewitt.com">
    <em:updates>
        <RDF:Seq>
            <RDF:li resource="urn:mozilla:extension:firebug@software.joehewitt.com:0.4"/>
        </RDF:Seq>
    </em:updates>
</RDF:Description>

<RDF:Description about="urn:mozilla:extension:firebug@software.joehewitt.com:0.4">

    <em:version>0.4</em:version>
    <em:targetApplication>
        <RDF:Description>
            <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
            <em:minVersion>1.5</em:minVersion>
            <em:maxVersion>3.0</em:maxVersion>
            <em:updateLink>http://releases.mozilla.org/pub/mozilla.org/extensions/firebug/firebug-0.4-fx+fl.xpi</em:updateLink>

        </RDF:Description>
    </em:targetApplication>
</RDF:Description>

</RDF:RDF>

I've been reading this blog over at sitepoint about Who Gets Rest by PHP heavy Harry Fuecks. It is a fairly link-heavy top level view of what REST is.

Its nice to see more the PHP guys get into REST, as far as PHP guys go, Harry is pretty Heavy. What harry has to say about URI naming schemes (especially in the comment section) really helped to gel a very important part of REST for me:

...another consequence [of removing verbs from the URI] is separating "tools" for working with "resources" from the resources themselves. That might mean to edit a blog entry you might have a URL like http://www.example.com/backend/editor which displays the form you need and POSTs to the resource (URL) to update it.

This really nails the whole "Hypermedia as application state" concept home for me. The GET request to /backend/editor returns a resource representation that can be used to make a POST request to /example.com/entry (or even a PUT request to /example.com/title-of-my-entry-here). The (machine or human) agent travels through the application like pseudo-medieval adventurers through a dungeon; the agent can go backward and forward through the application as they desire.

I'll get into this state-machine-design of a web application in a later entry.

This I think is going to be the biggest thing coming out of the Hi/Low REST debate: the understanding that REST is an architectural style. It is a method of designing your web services. Just as you can Design your building(be it a house, mall, skyscraper...) in any style you like, the same goes with how you are going to design your web application.

And because we are talking about an architectural style, it means you are free to break the rules if you like. Do you want to store state as a session ID and throw it around in a cookie? Fine! Go to! Call it "REST+Cookie State" (or perhaps, "REST - statelessness") if you like. But its style, which means the designer has latitude as to how much he or she takes from that style depending on their needs.

So with the concept of REST as an architectural style, lets take a peek at some web services: (Thanks to pwb who gave me the idea in the comments of my entry about Lo and Hi REST)

A RESTful evaluation of some webservices.

this is not a value judgement, but it is rather a way to define REST by talking about which constraints they break, and the implications of breaking each constraint.

When going through these services, it is important to note that all of these services maintain the state of the application on the client. So all of these services are RESTful to some degree.

Flickr

RESTful

• GET and POST are used properly. You must use POST to the flickr.photos.delete method, but you can GET the info of a photo.

RESTless

• The URI. Everything is handled through a single URI with a query string (like http://www.flickr.com/services/rest/?method=flickr.photos.delete). The URIs need to change to /services/rest/photo/photoid /services/rest/person/personid, etc. In doing so, the results of GET interactions could be cached by clients and proxies properly.
• HTTP Status. Errors return a 200 response code. Preventing proper caching of resources.

Notes

Sticking with POST and GET would still work for flicker, but obviously a DELETE to /services/rest/photo/photoid makes more sense then POST /services/rest/photodelete/photoid

del.icio.us

RESTful

• Good URIs; not great, but good. (http://del.icio.us/api/posts/get). del.icio.us still has the problem of the URI specifying the verb when it doesn't need to.
• Standard use of the HTTP auth.

RESTless

• Everything uses GET and URIs are named after methods. This prevents cachability, and breaks the rule of HTTP where GET methods must be safe.

Notes

No longer claims to be restful, but did at one point. I'm not the first one to point this out either. Delicious makes some use of HTTP status codes (503 if you hit the server too hard), but other times does not.

s3 (amazon)

Pure electric REST sex baby. Not surprising really, Amazon hires some smart people.

Also, Amazons documentation is a perfect example of how to properly document a REST web service.

RESTful

• Proper HTTP status codes
• Proper URIs (http://s3.amazonaws.com/bucket/object)
• Proper verbs on resources (GET, PUT, DELETE on buckets)
• Proper authentication using HTTP auth, and a bonus for exposing that on the query string if the client needs it.
• Excellent use of meta-data in the response header, including E-Tags, and special amazon extensions (prefaced with x-amz-*)

RESTless

Nothing I can see. The S3 REST API is an example of a well defined, well documented REST API.

Bloglines

• Proper use of HTTP status codes
• Proper URIs (http://rpc.bloglines.com/listsubs)
• All actions are retrieval only, and therefore follow the rule of proper verbs on resources (everything with GET)
• Authentication using HTTP auth

RESTless

• The http://rpc.bloglines.com/getitems resource has the potential to mark items as unread when passed a parameter to the query string. Ideally a POST request would be used to mark items unread, and a GET would not. Alternately, a PUT request could be used with a list of items to mark items unread.

Notes

Does not claim to be RESTful, but it mostly is.

Ebay REST API (pdf link)

RESTful

• Semi Proper URIs (http://rest.api.ebay.com/restapi), the URI really only counts for one resource, a set of search results.
• Proper Verb on the Resource (GET).

RESTless

• There is no mention in the documentation as to whether or not the Ebay API properly returns HTTP status codes, but my guess is that it does not. (Does anyone have any information on that?)

Whoah. Lots and lots of action is happening in the blogosphere about the division between Hi REST and Lo REST (which I argued is completely bunk, and still do).

First off, I should mention Koranteng Ofosu-Amaah who, like me, is all about the Elevator Pitch of REST, which he puts a whole lot more succinctly then I did. Good on him.

Mnot also talks about the false choice, but then we go right back into the conversation about which HTTP verbs to use.

Avatars and Definitions

I'd like to respond to someone on the "other side" of the discussion who is making a lot of waves, and, while I may not agree with what he has to say is zeroing in on some good stuff. Ryan Tomayko in his entry TitledThe Highs and Lows of Rest says:

Not being able to distinguish which of these subsets of applied REST one is referring to is hurting our ability to have meaningful conversations about this stuff. For example, consider the following conversation; I’ve seen it hundreds of times now:

Restafarian: 80% of developers use the XXX REST API because they find it easier to deal with.
Tool Vendor: That’s not really REST. It only uses GET and POST and breaks rule #5034
Restafarian: Oh yea, well SOAP/WS-* sucks.
Tool Vendor: Go write some PHP you dirty hippie!

I’d like that to stop happening.

But I don’t think adopting wrong or ambiguous terminology is going to help either. I’d like to register my nits with the few sentences that Dare provided and see if anyone else is thinking along similar lines.

To which there are a few things to say. The first of which, why is the RESTafarian a PHP writing dirty hippy? Have I become some kind of RESTafarian avatar?

Enough funning. The real part that merits a response is that having meaningful conversation about REST Is hard, because there is a real disconnect between what REST means and what people think REST means. In fact, I don't so much have a problem with the idea of splitting REST into a high and low version. What I take issue with is where the split is taking place. For instance, I could see a situation arise where cookies would be used to store an applications state, and this could still be RESTful, and we could call that Lo-REST. I would even go so far as to say that we could break one of RESTS constraints and we can call that Lo-REST. But the point is, that in order to make this Hi and Low REST distinction, we have to be talking about REST, not HTTP. In fact, One could argue that one doesn't need to use HTTP to be RESTful, and it seems to me that Fielding suggests as much in his dissertation when he talks about REST being applied to URI and HTTP.

Another excellent thing that Ryan brings up is the fact that the response entity of the server does not have to be XML for it to be rest. In some cases, a text/plain will be a perfectly valid, and usable resource representation. He also brings up Microformats as a good resource representation (AHAH is what this is called, and it is quite nice actually).

Web services as objects

Apparently my previous entry resonated with Sam Ruby as well, and through checking out his blog, I suddenly got transported into the world of Duck Typing and other misc goodness. Go check it out, you won't be wasting your time, he is on my feedlist. Sam Ruby makes the web-service to object analogy, which I like a lot more then the REST/CRUD analogy, but it still doesn't fit right with me.

I guess as an analogy it works really well with SOAP, since SOAP started out as the Simple Object Access Protocol after all. But I think that the analogy can be carried further, and perhaps expressed differently in the case of REST to promote more understanding (which is not to imply that Sam Ruby doesn't understand REST). When you GET /resource?my&query&string&here, what you are really doing is $myRepresentation = new Resource($my, $query, $string, $here)... and at about this point the analogy starts to break down. POSTing to a resource will perhaps alter the resource itself (thus changing the class), or it may just alter the representation of the resource (changing an instance, and all future instances that "look like it"), or, it may just initiate an action leaving the state of the resource unchanged, but otherwise modify or act on another resource. If you perform a DELETE on a resource, one of the actions that may happen is that a representation of the resource disappears, likened to unset($myRepresentation). But another thing that might happen is that the resource itself will disappear. The only analogy here is that you undefine a class (which only makes sense in a world where classes are first-class entities).

It is in the breakdown of the analogy that (hopefully) promotes more understanding. Essentially what I am saying is that with REST you don't want to think about methods on objects, you don't want to think about storage and retrieval of documents, you want to think about Actions on Universal Resource Indicators, that may contain a representation of a resource, that may return a representation of a resource. From Fielding:

What distinguishes HTTP from RPC isn't the syntax. It isn't even the different characteristics gained from using a stream as a parameter, though that helps to explain why existing RPC mechanisms were not usable for the Web. What makes HTTP significantly different from RPC is that the requests are directed to resources using a generic interface with standard semantics that can be interpreted by intermediaries almost as well as by the machines that originate services. The result is an application that allows for layers of transformation and indirection that are independent of the information origin, which is very useful for an Internet-scale, multi-organization, anarchically scalable information system. RPC mechanisms, in contrast, are defined in terms of language APIs, not network-based applications.

Notice that Fielding himself makes the HTTP vs. REST distinction here. (For clarity, what makes my above description RESTful is this talk about representations of resources.)

Cleaning up communication

It really is all about clarity of what REST is. REST is a general set of constraints that happen to be really well applied to HTTP. I happen to be working with an application server that is about 70/30 REST, its protocol has nothing to do with HTTP. However, it contains some (but not all) of the architectural constraints that are laid out by Fielding's dissertation.