In the classic "RESTful Web Services" book (O Reilly, ISBN 978-0-596-52926-0) it says on page 251 "Some firewalls block HTTP PUT and DELETE but not POST."
Is this still true?
If it s true I have to allow overloaded POST to substitute for DELETE.
In the classic "RESTful Web Services" book (O Reilly, ISBN 978-0-596-52926-0) it says on page 251 "Some firewalls block HTTP PUT and DELETE but not POST."
Is this still true?
If it s true I have to allow overloaded POST to substitute for DELETE.
Firewalls blocking HTTP PUT/DELETE are typically blocking incoming connections (to servers behind the firewall). Assuming you have controls over the firewall protecting your application, you shouldn t need to worry about it.
Also, firewalls can only block PUT/DELETE if they are performing deep inspection on the network traffic. Encryption will prevent firewalls from analyzing the URL, so if you re using HTTPS (you are protecting your data with SSL, right?) clients accessing your web service will be able to use any of the standard four HTTP verbs.
Some 7 layer firewalls could analyze traffic to this degree. But I m not sure how many places would configure them as such. You might check on serverfault.com to see how popular such a config might be (you could also always check with your IT staff)
I would not worry about overloading a POST to support a DELETE request.
HTML 4.0 and XHTML 1.0 only support GET and POST requests (via ) so it is commonplace to tunnel a PUT/DELETE via a hidden form field which is read by the server and dispathced appropriately. This technique preserves compatibility across browsers and allows you to ignore any firewall issues.
Ruby On Rails and .NET both handle RESTful requests in this fashion.
As an aside GET, POST, PUT & DELETE requests are fully supported through the XMLHttpRequest request object at present. XHTML 2.0 s officially supports GET, POST, PUT & DELETE as well.
You can configure a firewall to whatever you want ( at least in theory ) so don t be surprised if some sys admins do block HTTP PUT/DELETE.
The danger of HTTP PUT/DELETE
is concerning some mis-configured servers: PUT replaces documents (and DELETE
deletes them ;-) on the target server. So some sys admins decide up right to block PUT
in case a crack is opened somewhere.
Of course we are talking about Firewalls acting at "layer 7" and not just at the IP layer ;-)
im currently setting up asp.net to accept DELETE http verb in the application. However, when i send "DELETE /posts/delete/1" i always get a 405 Method not allow error. I tried to take a look at ...
I ve just finished an online service for shortening URLs (in php5 with Zend Framework); you can enter an URL and you get an short URL (like tinyurl and such sites). I m thinking about the API for ...
We re implementing a REST client on JRE 1.4. Seems two good options for a client REST framework are HttpClient and HttpUrlConnection. Is there a reason to use HttpClient over the JRE s ...
I m using the Spring RESTTemplate on the client side to make calls to a REST endpoint. The client in this case is a Spring app and Tomcat is the servlet container. I m running into issues making a ...
friendfeed.com uses 302. bit.ly uses 301. I had decided to use 303. Do they behave differently in terms of support by browsers ?
I have written a pretty extensive REST API using Java Jersey (and JAXB). I have also written the documentation using a Wiki, but its been a totally manual process, which is very error-prone, ...
We are re-developing our buyonline functionality and we are doing it the RESTful way. The process is a three step one and the customer is asked to enter data at each step. Let s say the three URL s ...
The Microsoft AJAX Library Preview 6 and jQuery provide several ways to make the sorts of calls I need: Sys.Net.WebRequest (ASP.NET Ajax) Sys.Net.WebServiceProxy (ASP.NET Ajax) $.ajax (jQuery) Sys....