I need to point out that I am new to REST and these posts are simply me thinking through these topics to obtain a better understanding. If you find something I’ve said to be incorrect, please let me know.
Simply put, REST design is about resources. To go further, REST design is about providing access to those resources in simple CRUD fashion. What is CRUD? Well it stands for Create, Read, Update and Delete. The basic actions one can perform on a resource.
Well, we obviously have more than those four methods. In fact the functional CRUD actions are: index, show, new, edit, create, update and destroy. This does not mean that each one of these actions will be seen in the path of the request.
Using a User model as an example:
Action Listing users Show user New user Create users Edit user Update user Delete userPath /users /users/1 /users/new /users /users/1/edit /users/1 /users/1HTTP Method GET GET GET POST GET PUT DELETE
As you can see, some of the paths are the same. For example, users/1 can be for showing, updating or deleting. That does seem a little odd, but it’s all about the HTTP method. The method determines the action to be taken.
These actions are part of the design consideration for a REST application. What does that mean? Well, when I am thinking about designing a REST application, I think in terms of accessing the data via a process, not user interaction. This forces me to design the resources in the simplest of manners. At least, that’s my goal. Don’t take this to mean this should ALWAYS be done. I don’t apply an ALWAYS rule to anything, that leads to trouble.
As I encounter more REST related issues I’ll post what I’ve learned. I had started to make a series on REST design, but I didn’t like that idea. It felt like I was restricting myself to continue the topic instead of writing about my most recent discoveries. I’m gonna chalk that up to another lesson learned on blogging.
Note: This is an updated version of the original post.
