Last time, I convinced you that the world wide web is a bunch of resources, not web pages. This time we will take another step closer to what REST is all about.

Object-Oriented Analysis and Design

If you've been doing object-oriented programming for some time, you probably learned to work like this:

1. Write a description of your problem domain - what your program is supposed to do.
2. The nouns are your classes
3. The verbs are methods on those classes
4. Have your nouns call methods on other nouns to accomplish a task

Sounds reasonable. That's how I did programming for a long time. This style of noun-verb programming is often called "RPC" style. I don't know what it has to do with "remote"-ness, but just know that "RPC-style" is the "classic" way of building object-oriented software. It's actually a great way to develop software. But that's not how the web was designed to work. Why not?

Imagine it's 1992 (or just sometime before the web as you know it today). And suppose three different companies developed three different software applications: one to buy books, one to buy airline tickets, and one that can provide aerial photographs from any arbitrary distance above the earth. They each followed the classic object-oriented modeling techniques outlined above to develop their apps. And thinking that third-party software might someday want to interface with their software, they each implemented their own API as well.

Now suppose it became your job to write a tool that would front-end all three applications.

Ugh. You'd have to learn three different APIs. And I bet you would have UI controls that would correspond directly to the methods you can call in each API. But it sounds logical, right? I mean, how else could you do it? Besides, it's only three different APIs, and you know of some good books that give you some design patterns you could use to try to reduce the complexity (and look cool to your co-workers).

How about a million APIs?

Let's think about the browser again. When you install it on your computer, it has no foreknowledge of what websites you will want to visit. Yet it can communicate with any website you want. Not only that, you can take actions on those sites: you can buy music, book airline tickets, and view satellite images of your house.

Is it magic? Think for a moment how impossible things would be if each website had their own API. To buy a book on Amazon, the browser would have to know to call the Amazon.Buy() method. And it would need to call the UnitedAirlines.CheckFlights() method when I clicked a button that said "Check Flights" on it. You just can't build a tool that would have to talk to a million different APIs.

That's why the web wasn't designed from an RPC perspective. It was designed from a REST perspective.

Resource-centric Design

According to Wikipedia, REST stands for Representational State Transfer. Well... whatever. All it really means is that instead of having nouns with an arbitrary set of verbs attached to each one, every noun (from now on referred to as a resource) will have the same finite set of verbs. In other words, every resource will expose the same API. The essential methods in this API enable any client tool to:

1. Obtain a read-only view of a resource
2. Create a new resource
3. Update the attributes of a resource
4. Delete a resource

Wait a minute! Which one of these methods means "buy this book"? Which one means "search for flights from Chicago to New York next Tuesday"? Which one lets me zoom in from "city" level to "street" level on a map? And which one lets a user login to the site?

We'll find out the answer next time. But I think you might know the answer already, if you really can stop thinking about the "buy the book" web page and start thinking about what resource you might be creating. See you next time.

Questions? Suggestions? Leave a comment and tell me.