Geek Answers Handbook

REST API Design regarding DELETE method

I am creating a REST API. in fact, I understand the general guidance and rule.

But I have a problem with the DELETE method, because I need to send data by body in the request, which the DELETE method will ignore the body.

If you ask what data forces me to send it to the body using the DELETE method, these are the "url" and some other parameters. Of course, "url" has an id in the database, so I can use DELETE without problems, for example DELETE https://api.example.com/content/url:url_id . But instead of passing the identifier, I decided to pass it to myself and other parameters. my business logic and requirement make me pass the url, not the id in the DELETE method.

therefore, after reading, I also find some blocking of the DELETE and PUT proxy. and also the HTML form only supports GET and POST methods.

I'm starting to think that it is better to use GET and POST in my REST API. so that I can POST user to delete both an object or resource like this:

 POST /content/delete/url Body : url : xxxx param1 : xxxx param2 : xxx

But the REST API Design rulebook, O'reilly, page 18 says

"HTTP request methods should be used to indicate the CRUD function is running."

The following anti-patterns illustrate what not to do:

 GET /deleteUser?id=1234 GET /deleteUser/1234 POST /users/1234/delete

after searching and reading again, I came up with some solution

  • using X-HTTP-Method-Override

  • using api method name, such as flickering (api.flickr.com/services/rest/?method=flickr.collections.getInfo) and mailchimp(api.mailchimp.com/1.3/?method=campaignDelete)

It seems to me that I like solution 1 to use the "X-HTTP override method". What do you think?

Google seems to be using an X-HTTP override method, will respond to this https://developers.google.com/gdata/docs/2.0/basics

Label name Flicker and Mailchimp, as in solution 2

+4
source share
3 answers

I know this is part of your business logic, but I would recommend that you rethink it or perhaps try using a different solution instead of REST.

By doing things like the ones you mentioned, u will violate all REST concepts and still not do something good enough for your application.

I think the best solution in your case would be to think about your business logic. Maybe this can be done without a REST break.

If you think this cannot be done, then I would recommend the first solution u listed on the list. He feels wrong.

Hope this helps.

0
source

You CANNOT send a body with a DELETE request. and that doesn't make sense!

RESTful will be

 DELETE http://www.plocal:3000/api/v1/content/page-1 DELETE http://www.plocal:3000/api/v1/content/info-page DELETE http://www.plocal:3000/api/v1/content/1 DELETE http://www.plocal:3000/api/v1/content/2

testcall with

 curl -v http://www.plocal:3000/api/v1/content -X DELETE
0
source

Does the URL indicate the identifying information of the content item? If yes,

 DELETE https://api.example.com/content/:id

And include url as part of the id. The identifier does not have to be a strictly integer.

You can also create a new route.

 resources :content, :except => [:delete] do member do delete delete_by_url end end

And then you will have a new delete route with a more suitable name and specific action in the controller.

 DELETE https://api.example.com/content/:id/delete_by_url
0
source

More articles:


All Articles