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?)

Steve Yegge is a god damned genius.

If you write code, you need to run—not walk—to his blog and read it.

Right. Now.

Via Greg. Another god damned genius.

I've been remiss lately about keeping up to date with HTML 5. To be honest, I am a little scared, Microsoft is only just coming out with a new version of Internet Explorer that might actually be HTML 4.01 and CSS 2.1 compatible. They might... soon... maybe? So I am hesitant to start playing with some new tech that will be implemented many years after the fact.

But damn, there is some cool stuff inside of the HTML5 working draft...

First, a little rundown of what is in there

• More semantically named containers. This is just a fancy way of saying: less <div> blocks with classes, more structural elements. Instead of <div class="nav"> or <div class="footer">, we get <nav> and <footer> elements. HORRAY! Some of the more interesting elements are: section, nav, article, aside (for a sidebar), header and footer.
• The canvas element, which allows you to paint on it using Javascript, and has an astounding number of 2D graphical methods, including gradients, paths, inserting images, using images or other canvases as patterns, scaling, translation and rotation. The only thing that is really missing is the drawing of text, which when you look at the problem of figuring out font metrics across a wide array of platforms with a wide array of display capabilities, you can see why.
• A few additions of inline elements, such as: t (for date and/or time info), gauge (for a static gauge, like a rating) and progress (for a dynamic progress bar). Again, good semantics, good stuff.
• Some microformat specific tags, such as calendar and card, which will take the child elements, and attempt to parse them as a hCalendar and hCard.
• A datagrid element, which is like a table, but is meant to be updated, added to, subtracted from, or sorted dynamically.
• Menu and Command elements, that are for building things like toolbars, context menus, and such.
• Forms are getting a new face-lift, mostly from another specification, which means a whole new schwack of input types (dates and times, URLs, numbers, etc.) and validation (mark inputs as required, set maximum and minimum limits), regular expression validation (!), auto-complete, PUT and DELETE methods are allowed (WHOO HOO!), definitions as to how forms should be posted to different schemes (i.e. you could PUT the results of a form submission into a file:, ftp: or mailto: scheme. )
• Client side persistent storage. Ho-lee carp. This is like cookies plus plus (pronounced ploos ploos). Essentially they are like cookies, but they are much better defined. There is the sessionStorage which is specific to a single browser window, and single domain only. But there is a globalStorage, which is persistent across windows, sessions, and potentially even domains. You can set up values inside of the globalStorage that are accessible to all domains, all .net domains, or all jonnay.net subdomains, or just the blog.jonnay.net subdomain. Yes, I'm worried too. But surely someone thought about how dumb this is. And even if they didn't, you'll be able to disable the globalStorage object across domains and subdomains, right? right?
• Editing pages in-line. Yup you heard me. Imagine noticing one of the ubiquitous spelling or grammatical errors on my blog, and just changing it right then, and right there, and then the server lets me know that someone suggested a correction... and BAM! This looks like powerful stuff, and would completely transform wikis as we know them.
• Server Event Model. Whoah. Server-Push. Nice. Essentially a persistent connection is made to a client, and information is sent to that client when the information is available. This is different from AJAX/XmlHttpRequest.
• There is a cross-domain cross-document messaging protocol (!) which allows the transmission of messages from one domain to another in a secure way. This looks really cool, but also looks really dangerous.

Remember, this is a first draft, so things will be changing.

And some ranting ensues...

The sad fact of the matter is, chances are companies like Google are going to get right behind this specification, but Microsoft is going to take one look at this spec, and (if they haven't already) reject it out of hand. I doubt they will do so much as badly implement it. They will send their people into the W3C to subvert it, and make sure that it never hits recommended status. Why? Because this specification is more then just HTML, it is the Web Applications Specification 1.0. Which is about to render large chunks of your operating system null and void.

Which makes me think... perhaps the definition of an operating system is already in transition. The more useful, and interesting web applications become, the more time I spend in my web-browser. There will come a point where home computers and operating systems become less about running separate applications and more about storage and retrieval of information from the intarweb. The storage is no problem, we've been doing the right-click-save-as tango for years. It is the secure retrieval that is going to be interesting. I could files being laid out in different zones: The world, The tribe, The users, and You. As per usual, there would be read-write permissions. "The tribe" is more a zone place-holder. You might have 4 or five similar zones, one for family, one for friends, one for work, etc.

At any rate, operating system design is going to change radically over the next few years, and there seems to be a few major models:

• The Microsoft method, which is to make every computer a client, and not capable of being a server unless you buy the Microsoft 20X6 (twenty-exty-six) Server for $5,000, and takes a team of 20 MCSBs (Microsoft Certified Strong Bads), and really only Microsoft Clients talk to Microsoft Servers.
• The Apple method, where every computer is a client, and every computer is a server, and is generally compatible with any other client and server out there, as long as they talk in standard methods. Although if an Apple talks to another Apple, much hipster-love ensues. This is different from the Microsoft model, because while Microsoft seeks to extend the current specification (and thus breaks it), Apple extends the current specification, according to the specification, thus not breaking it.
• The OSS method, where every computer is a server, and can be a client too. Strictly standards compliant where possible, and tries hard to work with the other two proprietary models with various degrees of success.

Note that these are just generalizations. Apple can be just as good at the Microsoft game (iTunes DRM anyone?), but generally it seems to me that the platform is about: standards first, extensions and user experience second, without compromising both. Also, note how Microsoft is going to be circling the waggons over the next few years. They've talked about standards and interoperability, but in fact they will be doing nothing of the sort. They are going to be trying very hard to maintain the iron-grip of control they had before Linux and OSX hit the market, but that will be hard, as more and more people notice that there are better, more functional alternatives.

Whoah. That got ranty. Sorry.

Greg, who always has interesting stuff to say has written this well thought out post on Programming Languages and Religion. If you aren't a code geek, don't be scared off. Just think of it as an allegorical story.

Go read it right now. I'll wait.

This brings up a few questions, mostly on the introspective side: Does Scheme count as a Lisp in this big rant? I.e. would Greg rather hire a Schemer then a Java'er? (Javer? Javanese?). What is my favourite language out of the list of languages I know? Have I shut myself off learning a new language? (Answer: yes. I need to learn Ruby. Not Ruby on Rails, but straight up Ruby. I want to get into a language with continuations again. I don't want to get into more web programming.)

So thinking about what my favourite language is, I would have to come at you with two languages, for 2 very different reasons. But first off, a list of languages where I have some degree of fluency in, so that you can get a sense of context: C, PL/B, Haskell, PHP, Scheme, Java and Javascript. I can also refactor and work with existing Python and Visual Basic. So the two favourites? This should come as no surprise: PHP and Scheme... for 2 very different reasons.

I love Scheme because its pure and its expressiveness is outstanding. What takes 10 lines in other languages takes 1 line in scheme. Even how scheme handles identifiers is slick (predicates end in a question mark, functions that modify existing data end with an explanation mark. I.e. 'integer?' tests to see if a number is an integer, 'set-car!' modifies the head of the list to a particular value). It, as I have said before, is the waffle-suit of languages.

I love PHP on the other hand because it is usable. It makes a great choice to get a simple web app done, or even a shell script. There is a variety of libraries and functions available. More often then not, it just gets out of the way and stays out of the way. PHP also happens to be the current whipping-boy-du-jour. All the fucking painful hipsters are too busy being snooty with ruby on rails, and the "Real Programmers" still think Java is the second coming of Christ (let me fucking tell you, this is hilarious; in 97, Java programmers got that treatment. What goes around neh?)

Everyone has a language they love to hate, PHP, Java, Visual Basic are all big ones, but their hate is mostly tied up in the languages they love. (Consider the Java vs. VB or ASP vs. PHP debates). But they all do not hold a candle to PL/B. Seriously. People who say these languages suck really have no idea. Okay, Visual Basic is pretty bad, but you can make it workable. You can write good code in Visual Basic. PL/B however is a plague upon this earth that must be wiped clean. I have never before seen a language that encourages shitty code like that one. You think Visual Basic teaches bad habits? HAH! PL/B is the essence of bad habits. Global variables are encouraged and abstracting code is difficult. The primary unit for code abstraction is a routine, which is like a function or procedure, except it is in the global scope. The only thing that changes is that the instruction pointer changes, and a stack is kept for return addresses. One implementation of PL/B just got actual functions, with their own scope. They also have a very odd set of rules concerning what can and cannot be done inside of said function construct.

Most people do not know how much a language can suck.

That is to say, REST does not equal CRUD, dammit!

Sadly, even I made the flawed analogy of Rest and CRUD. It is an excusable one, because it is so easy to map POST to create, and PUT to update, but this misses the deeper semantics of the HTTP verbs, a mistake that I corrected in a later entry. In short GET, PUT and DELETE refer to specific resources, and in the case of PUT, the resource does not have to exist for it to be acted upon.

But perhaps more importantly, by shedding the CRUD (Create, Retrieve, Update, Delete) mapping from GPPD (GET, POST, PUT, DELETE) you can use REST the way it was supposed to be used. There is nothing wrong with using a POST to delete, update or create resources, as long as you are POSTing to the proper resource. For instance, you might DELETE /table/employee/emp723, or you might POST an entity containing delete instructions for ids 23, 237 and 239 to /table/employee. A POST might not actually alter the data of a resource, but might initiate a different action entirely. A post could, for example, tell a server to update a series of feeds.

Making the REST = CRUD analogy is flawed, and isn't helping the understanding of REST, rather it is limiting it, and turning HTTP into an SQL subset.

About the only thing more passé then web 2.0, are the declairations that web 2.0 is dead.

It's been a little while since I have ranted copyright. But This article just pisses me off to no end.

Music sales in Canada dropped 4% in 2005 to $536 million, the Canadian Recording Industry Assn. reported Thursday.

The dip is part of a 10-year decline that the CRIA blames on illegal music downloading.

Except, the RIAA, the big brother to the CRIA, as been known to fudge their numbers, and claim things like music sales are dropping, when really they are gaining in the face of a recession. So have music sales really dropped 4%? Does it have to do with piracy, or does it have to do with the number of music retailers online? Does it account for non-Canadian music e-tailers that sell to Canadians? I don't know the answers to these questions, but I rather suspect it goes something like "We cherry-pick whichever makes it look like we are losing the most money!"

Maybe the real answer to the question is that Canadians don't need to buy that pop album because it is all we on the radio. I don't know the state of radio for the rest of Canada, but if Calgary is any indication, it is pop, rock, more pop, and a little bit of country. To be hones,t I haven't really looked into buying music online, but I rather suspect that a dollar per song is about right. So, say a full CDs worth of songs (call it 10-12 songs) is almost equal to the cost of a music CD (10-15 dollars). They're selling bits. There is no artwork, no packaging and no inventory. Shipping is incredibly fast, easy and cost-effective. Why aren't the savings passed on to the customer?

Another problem. "Illegal music downloading"? Errr... no. It is legal, according to the Supreme Court of Canada and our current copyright legislation. But what gets me is this quote from the CRIA head honcho:

"As legal downloading surges ahead in other parts of the world, Canada is marooned on the sidelines," said CRIA president Graham Henderson. "The goal of a vibrant digital marketplace in Canada will remain beyond reach until our legal environment encourages people to buy music instead of passively accepting theft on the Web."

So wait a second. You lobby to get higher levies on blank media, because Canadian copyright law allows private copying, and you get it. Now that you have it, you want Canada to make private copying illegal? So you want to have your cake, and eat it too then? I see.

Funny how this "News Article" from variety just listens to one side of the story. Sounds to me like they got it from a press release.