If my web service allows the clients to do **deletes** using **POST** requests, is it still considered RESTful?

If my web service allows the clients to do deletes开发者_JAVA技巧 using POST requests, is it still considered RESTful?

Strictly speaking I think that it is not, although I would still consider it RESTful. There are times when it is not possible to use all of the HTTP verbs, this causes many REST APIs to allow other actions via either POST or GET.

I don't think the question should be whether the API is "RESTful" because that has become a buzzword. A more important issue is whether this is a good use of the HTTP protocol, which is defined in RFC 2616. Here is the relevant section: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html.

It says "The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line." POSTs are normally used to create a new item in a collection or annotating existing resources. While annotating something by deleting it isn't actually prohibited, and there are no issues of safety and idempotency to be violated, doing a delete on a POST is not using HTTP as it was intended.

That said, if you do a POST to modify and existing resource by "setting a delete flag" within the resource, you would be following modern RESTful API practice. But to completely whack it? No, that is what HTTP DELETE is for.

As there is no official RESTful standard, you're fine as long as the method 'override' is explicitly passed in a parameter, such as method=DELETE.

The short answer is no, although from a practical standpoint it might be easier for clients to implement, particularly if they are unsophisticated and don't know how to do a DELETE.

With that said, it's your web service, so you should do whatever best meets your business needs. A complete implementation of REST is much less important than great client documentation of how to operate your API.

No it isn't RESTful in the way that HTTP is intended to be. A way to allow clients that do not support DELETE or PUT to interact with resources that are designed to support them is to use a custom header that indicates which operation to perform. Then have a layer in your framework inspect that header and call the correct method in your resource code. The approach that I've seen used most widely is to use a header called X-HTTP-Method-Override. If the client cannot manipulate HTTP headers, then the same approach (event using the same name) can be used with a request parameter.