News Stay informed about the latest enterprise technology news and product updates.

REST recommended for Web services coders

Representational State Transfer (REST) is the ideal strategy for developing Web services, especially using Ruby on Rails, says author and consultant Bruce Tate.

Bruce Tate is an author and independent consultant in Austin, Texas, and an advocate of lightweight development with Ruby on Rails. Having worked for 13 years at IBM, in roles ranging from a database systems programmer to Java consultant, he contributes articles to the IBM DeveloperWorks Web site. We talked to him about his enthusiasm for building Web services with REST and, of course, Ruby on Rails.

For those who may not be familiar with Representational State Transfer (REST) can you give us an overview of it?
REST is essentially from a dissertation by Roy Fielding. For a dissertation topic, he chose to write about Web architecture models. He looked at the way people solve traditional Web services problems because the Web was around a long time before any of the WS-* specifications. He found a pattern where programmers would use existing standards to effectively handle Web services requests. If you think about it, the whole Web is a bunch of little Web services and these Web services basically serve content. The way that we use them is we access named resources. We use the HTTP protocol, and we get a structured response back. So if you bend your brain a little bit, think of HTML as a more specific XML. If you think about Web services in that vein, it's just an HTTP request to a named resource, and XML comes back. This opens up a whole new way of thinking about services. A REST-Web service is basically a simplified model where everything is wrapped around the HTTP send/receive protocol. So where did the concept of REST come in?
You can think of Amazon as a database itself. You can do things like an HTTP "get" and then you can pass "/book" and an ID of a book, and get a single book back. Or you can do HTTP post and then pass the form with all the particulars about a book to update it. There's an HTTP verb called "delete" to delete things and an HTTP verb "put" that will let you insert things. So you have all your CRUD methods: create, read, update, delete. That's REST. That's really all there is to it. Is it the simplicity of REST that makes it so attractive?
Yes. It's simple. It does most of what you need it to do. It has a security model built in, secure sockets. It has a network structure built in because you can put a link to a net resource in a document. So you can do composition that way. You can have a list of books, and they can have links to books or they can be links to other lists of books. REST changes the way you think about how you structure applications. You're mimicking the Internet instead of trying to decide what a method is. That model is just very, very effective. Why should developers look to REST as a model for building Web services?
It's a nice well-understood model. We know it. We've used it for 15 years as the Web. The Web is one big fat REST implementation. Anybody who has been doing e-commerce -– eBay or Yahoo! or any of those types of services –- they use REST. If you need more information, you embed the request parameters into the URL. It's easy to do. What would be your recommendations for developers looking at REST for Web services development?
Developers looking at Web services should look at REST first. I have a strong philosophy that you should pick the simplest approach that works and only go away from that when it breaks, when it fails. The REST model really hasn't failed. It really doesn't fail for 80 to 90 percent of what we want to do. And all the complexity in the WS-* specifications goes to serve the 5 or 10 percent of the most complex implementations. What about that other 10 percent?
If you think of what you would integrate with WS-* Web services, the IBM and Microsoft model, is basically for integrating big vendors and that's it. To get those vendors' platforms to talk to each other, they have to be on the same API. Since there are so many APIs and so little testing across vendors, the integration experience is absolutely horrendous for anything beyond the most basic integration, or the best-traveled roads. So are you saying REST is an alternative to either the WebSphere approach or the .NET approach?
Yes. You can use REST with WebSphere, .NET or WebLogic. If you're talking about, "How do I implement a REST server with Java?" you implement a servlet and pass XML back and forth. Java developers know how to do that. They've known how to do that for years. How about in the .NET world?
You implement their servlet equivalent, which is ASP in some cases or other APIs. So are you saying REST can work with WebSphere or .NET, but it's an easier alternative for developing Web services?
Absolutely. Where does Ruby fit in with REST?
Specifically Ruby on Rails has a very clean, very productive approach for building REST-based Web services. I would say you can do it with a quarter of the effort of a traditional Java Web service. Beyond productivity are there other advantages to building REST Web services using Ruby on Rails?
For more information
REST and Web services: The ZapThink take

What are the benefits and limitations of building services with REST?

Another advantage is that Ruby on Rails is an exploding platform. Ruby on Rails applications need to talk to other languages and other technologies and REST is a good way to get there. Is there anything else we need to know about building REST Web services with Ruby on Rails?
There's one more thing that you need to know. There's another model being built into Rails that's called SimplyRestful. David Heinemeier-Hannson, the founder of Rails, has outlined an approach to make REST even simpler on Rails. That means the Rails Web services support is about to get better. And second, there's going to be a major re-work of Rails Web services in the next release. That's very different from the Java approach where you try to maintain backward compatibility at all costs. It's going to leave some Rails customers out in the cold. But it's also going to provide a path for them to migrate. More importantly, it will let the Ruby on Rails platform continue to improve rapidly. That's a nice counterpoint if you're looking at how .NET and Java grow versus Rails. As Rails grows it isn't bloating as quickly because they are not afraid to take things out of the language that aren't a perfect fit. Is there a timeframe for SimplyRestful?
It will be in Rails 1.2 and we're talking months rather than years.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.