Seth Ladd's Blog

Dear MySQL , I know you just got bought by Sun, and are now swimming in money and possibilities. Please continue this momentum by formalizing your connection to the Web by including a RESTful end point in your next version. The Web is where you grew up and matured, and it's time to give back. The architecture wars are nearly over, and REST has proven time and again to be the dominant architectural style for Web applications. You, MySQL, need to expose your data via REST to promote interoperability across clients and further cement your place as one of the top databases for the Web. This is low hanging fruit. Your URL space is well defined, as you have databases, tables and views, rows, and columns. The HTTP methods (GET, PUT, POST, DELETE) map very well to your SQL DML methods of SELECT, INSERT, UPDATE, and DELETE. I'd imagine your URL space to be something like: /databases /databases/NAME/tables /databases/NAME/tables/NAME/rows /databases/NAME/tables/NAME/rows/PK U...

Enjoying Sam Ruby 's latest post titled Connecting , I was reminded that designing a RESTful system means much more than just adhering to a uniform interface (often the first attribute of a ROA that is promoted). When designing a Resource Oriented Architecture, you mustn't forget about hypermedia and how your resources link to one another, and how those links are expressed through your representations. Which brings me to JSON . A nifty little format, indeed. And one that, if you are building a modern web service, you should be investigating and implementing. However , if you are indeed building a hypermedia system with JSON, how do you express your links? I know how to do this in XHTML and RDF, but not sure how to express or render a URI and have it mean "link". I've love to be able to do something like this: { "name": "Cool Beans", "account": "http://example.org/accounts/23242342" } However, any JSON client will hav...

Thinking about REST or need to address some lingering concerns about adopting REST? I found the article Addressing Doubts about REST full of pragmatic, down to earth answers and advice for comparing REST and WS-* (or, RPC). Nothing new, but a solid collection of answers to how you should think about REST and how you should apply it to your system. I especially appreciated how the author points out that if you are worried about transactions across your systems, that's probably a design smell and you want to re-think your approach. Never expect that transactions will work reliably across many systems. Instead, build in logic to recover from error states. This is not a REST issue, but instead a large system design issue. REST simply makes it easy to pass the state of your resources between systems.

One of the reasons I love Rails is the built in support for REST. If you're not yet writing your Rails applications RESTfully, then you're not really writing web applications. I'll detail an example that I just created which I thought illustrated REST support quite nicely. In Rails, you can model singular or plural Resources. A plural Resource might be Users, which means you'll have lots of Users in your system. In contrast, you can create singular Resources when there is only one instance of that Resource in the system. A good example of a singular resource is an User's avatar icon. For instance, most Web 2.0 applications let you upload a tiny picture that represents you. In Rails speak, we say a User has one Avatar Icon. An Avatar Icon belongs to a User. When creating the URI space for these models (User, AvatarIcon) you use map.resources and map.resource inside of your routes.rb file. We want to enforce that an AvatarIcon belongs to an User in the U...

Nearly every web application has the concept of users or accounts. While the concept of a user or account is quite universal, when you get to implementing, you find out that the business rules and implementation details vary widely from application to application. Luckily for your Ruby on Rails applications, there's an excellent starting point for creating the basics of accounts and logins. The restful_authentication plugin for Rails provides generators for Users and the basic framework required, such as email activations, logins, passwords, controllers, and database migrations. The extra bonus is that the plugin uses REST to model the authentication. In the REST web application world, all you see are objects, or nouns. The verbs in the system are limited to the HTTP methods such as GET, PUT, POST, and DELETE. REST advocates that you interact with the world (your nouns) with these four methods. It forces you to think, "How would I convert an Action into a Thing?"...

RESTify DayTrader , in which Joe Gregorio converts a real world J2EE application's interface into a REST interface. Perfect example of how to do REST with real life requirements.

A brief history of Consensus, 2PC and Transaction Commit , in which Mark Mc Keown attempts to keep us all in sync with the history of consensus across processes in a distributed system. Excellent read. Thanks Mark!

InfoQ has an Interview and Book Excerpt from the book RESTful Web Services , the new book published by O'Reilly . I've ordered my copy from Amazon already, and I'm looking forward to reading it. The interview also links to a sample chapter from the book, titled The Resource Oriented Architecture. A great quote from the interview, by Sam Ruby : I also wanted a book that rose above the “we are 733T, WS are the Sux0rs” zealotry that, sadly, one too often hears. Congrats to Leonard and Sam on their book!

wadl is the Web Application Description Language , which is an XML specification to describe RESTful web services. Seeing as the current version of the spec is a mere 31 pages, I am excited to see this move forward. Many people would consider the lack of a description specification from REST web services a set back, so having a simple spec like WADL can be used to help the converts. I can see a future version of Rails generating WADL documents natively.

Tim Bray writes a nice explanation of REST . I love collecting this stuff in order to convert ^H^H^H teach my friends all about the "yummy goodness" that is REST. And hey, any name that reminds me of naps has got to be good.

Luke Redpath makes a valiant attempt to DRY up RESTful Rails controllers as he writes Refactoring REST: searching for an abstraction . I can see how this can be very useful if your controller methods follow the simple paths. Good to see some implementation patterns emerge that build on the assumptions that your controller is RESTful.

I sent a helpful PDF on Rails support for CRUD and REST to a buddy of mine. He asked for some clarifications. Here's what I sent to him. Try to think in nouns, and not verbs. Nouns are your Model classes, things which you can have instances of (User, BankAccount, Book, Login). That last example, Login, is where (hopefully) the light bulb goes off. Consider if you could only Create, Read, Update, or Delete *things* (nouns). How would you do a login? One way, the old way, is to add a login method on your user controller. Think about what you're saying. You want to call the method (or *verb*) "login" on User. Already you can see we've left the CRUD methods, and a warning bell should go off. If a user authenticated via User.login, what artifacts are generated? Are you simply returning a boolean? If so, how do you track logins? How do you ask "When was the last time I logged in?" To solve the problem, you noun-ify the concept of login. Create a ...

Restful Routes talks about the new RESTful programming models that are now possible in Rails (now in Edge, soon to be in the released version). In this case, the url /comments/1;approve would be created. The rationale is to use the path to the left of the semicolon for a resource’s identity, and to use the path to the right of the semicolon as a modifier. Frequently this modifier would be an operation that you would perform on the resource, such as approving a comment that requires moderation. This isn't very restful. This modifier hack is just another way to force another verb into the mix. The best way to be more RESTful would be to PUT a representation of the comment with the approval flag set to true. In REST, representations of resources are exchanged. Instead of referencing the URI of the comment, with a verb modifier stuck on the end, send along a representation of the whole comment. Now, you're saying, "But how do I do that in Rails?" This is, of course, ...

Resources on Rails highlights some of the new exciting changes to appear in Rails 1.2. The most exciting is ActiveResource, which CRUDifies models as HTTP resources. Go REST!

Don't say CRUD say FUC'D. On how Rails is seeing the true light with CRUD, REST, and HTTP.