Let's take a look at a sample of what RESTful URLs might look like. In this sample, let's "RESTify" a help desk service. This help desk service is responsible for managing support tickets. Each support ticket also has a list of work items that contain a log of the work done by support personnel on that ticket. The help desk service also needs to support searching, but in a RESTful manner. This is done by considering the collection of search results to be its own resource. Here are some sample RESTful URLs:

Another common use of REST is to use a slash (/) or semi-colon (;) to further subdivide a resource into views. For example, if you wanted to look at the list of helpdesk tickets but you wanted the "newunassigned" view (which is a really handy view to have!), then you might use the following URL:

/helpdesk/tickets/newunassigned

or

/helpdesk/tickets;newunassigned

A lot of Ruby folks seem to dislike the semi-colon syntax as they think it's "old school", but I like it as it visually distinguishes between a sub-view of a resource and an actual sub-resource. This gives different weight to the "newunassigned" sub-view than a sub-resource like "orderitems".

So how do you go about taking a problem domain and converting it into a service that adheres to RESTful architecture principals? Here's a few guidelines that I use when doing this myself:

1. Identify Resources
   In this step you want to take a look at your problem domain and the data flowing through your system and see if you can identify the resources available to clients that will eventually be exposed via the service.
2. Identify how client applications will use resources
   Once you have the list of resources, construct a set of use cases for how client applications will access those resources. This is often an overlooked step but it can be extremely englightening and highlight potential areas where your list of resources may need to be re-organized. Remember that resources are logical resources. If you find you have a 1:1 mapping between SQL tables and resources, you need to go back to the drawing board.
3. Construct RESTful URL schemes (service contract)
   Using the information obtained in steps 1 and 2, build your URLs. These URLs are essentially the service contract for your RESTful service. Think of it as really, really simple WSDL - just a list of URLs. At this point, don't worry about the message payload format - you can build that later.
4. Utilize REST URLs in test cases/sample scenarios
   Now that you have your URLs, run through some sample scenarios and use cases for your client application. Usually what happens is I find that I've got about 75% of your URLs right but the rest need work.
5. Refine
   Finally, take the knowledge you gained in step 4 and repeat steps 1 through 4 until you can get through step 4 without finding any obvious flaws in the URL scheme. Now you can get down to the dirty business of defining your payloads (probably with XSD if you're doing a regular POX implementation) and actually coding up the service and client.

So what does all this mean and why am I posting this? The Web Services scene has changed tremendously since I first started this blog a couple of years ago. A couple of years ago I didn't know much about REST, I wasn't doing anything with social networking, and most people in the industry were thinking, "Web Services? WTF. Just another stupid fad." They couldn't have been more wrong.

So now I'm taking my thoughts on Web Services applications from having spent the last 6 years of my life building them. I remember back in the good old days when they weren't called Web Services and what we were doing was "hacking HTTP to take XML payloads", probably because we were building distributed systems that couldn't communicate properly via DCOM or CORBA. We've come a long way since then and I want to do this series of blog posts covering my thoughts on Web Services as they stand now. This is all my own personal opinion, so feel free to ignore it or flame it, I'm doing this as much for my own edification as I am for yours ;)

Enjoy, and more posts will be forthcoming!