0

I read an example of restful service, it only uses two HTTP method: get post. for example, there is a task list at the server. To design the restful URL, we can use:

www.example.com/task    GET. return all the task list. 
www.example.com/task/id  GET. return the specific task.
www.example.com/task/create   GET. return a task form.
www.example.com/task/create   POST. post the data from task form page.
www.example.com/task/update/id  GET. update a task with id, return a task form page.
www.example.com/task/update/  POST. update the task from the task form page.
www.example.com/task/delete/id GET. delete the task with ID.

In this way, the URL is very clear, user can understand the meaning of the URL. Is this a good practice of restful URL definition?

Should we use PUT, DELETE operation? If so, how to design for the upward URL? Thanks.

unor
  • 92,415
  • 26
  • 211
  • 360
Jimmy
  • 1,699
  • 2
  • 16
  • 17
  • 2
    Using `GET` to cause deletion is a really bad idea. If a web crawler (e.g. google) ever accidentally gets pointed at your service (via just one errant link being publicised somewhere) it'll probably work its way through everything and delete it (because it automatically `GET`s any links it can get hold of) – Damien_The_Unbeliever Oct 14 '14 at 10:48

3 Answers3

2
www.example.com/tasks     GET return all the task list. 
www.example.com/tasks     POST Create a new task
www.example.com/tasks/id  GET return the specific task.
www.example.com/tasks/id  PUT update the task
www.example.com/tasks/id  DELETE delete the task with ID.

IMHO that's all the methods you need to have to deal with Tasks.

  • Use nouns but no verbs
  • Use plural nouns
  • Use HTTP verbs (GET, POST, PUT, DELETE) to do CRUD
max
  • 96,212
  • 14
  • 104
  • 165
NMK
  • 1,010
  • 10
  • 18
  • 1
    Edited: I believe you mean CRUD and not [CURD](http://en.wikipedia.org/wiki/Curd) – max Oct 15 '14 at 14:51
1
www.example.com/task            GET. return all the task list. 
www.example.com/task/id         GET. return the specific task.
www.example.com/task/create     GET. return a task form.
www.example.com/task            POST. create a new task
www.example.com/task/id/update  GET. update a task with id, return a task form page.
www.example.com/task            PATCH|PUT. update the task from the task form page.
www.example.com/task/id         DELETE. delete the task with ID.

I would say that a better API would be one that actually uses the HTTP verbs to describe what each action should do.

I also think it´s better to preface with the entity ID (/task/id/update vs task/update/id) since it makes it very explicit that we are acting on an entity.

max
  • 96,212
  • 14
  • 104
  • 165
1
www.example.com/task    GET. return all the task list. 
www.example.com/task/id  GET. return the specific task.
www.example.com/task/create   GET. return a task form.
www.example.com/task/create   POST. post the data from task form page.
www.example.com/task/update/id  POST. update a task with id, return a task form page.
www.example.com/task/update/  PUT/POST. update the task from the task form page.
www.example.com/task/delete/id POST/DELETE. delete the task with ID.

This example is almost good.

  • GET - to get resources, and GET request will NOT change anything. So use it to READ ONLY data, and get static resources, like html pages
  • POST - to commit changes
  • DELETE - use it support REST types, but you can also use POST-never use GET for delete operations
Beri
  • 11,470
  • 4
  • 35
  • 57