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 user
Path
/users
/users/1
/users/new
/users
/users/1/edit
/users/1
/users/1
HTTP 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.

0 comments:
Post a Comment