httpverbs

When evaluating that a form was submitted, I check that the method was post, not get. I was told this is a good way to know that the form was submitted by clicking the submit button and that it's not just being submitted by a script that's passing the data in the url. How about the "put" method. It seems very similar to "post". Can it be more or less be used instead of "post" without much loss in the benefits provided by "post"? No. HTML only supports post and get as form methods , even though HTTP has others. Even outside the context of an HTML form, the answer is still no as PUT and POST are

I'm new to this game so I might be misunderstanding things. Actually, if someone tells me that I'm misunderstanding things, it will be a favor. Maybe this person will be considerate enough to show me the right path. But... One of the " guidelines " or " best practices " of REST as it applies to Web Services ( http://en.wikipedia.org/wiki/Representational_state_transfer#Applied_to_web_services ) is that you should use the proper HTTP methods when making calls (did I misunderstand it?) to REST API's. But looking at many API implementations on the web, what I see is that 100% of the calls made to

If you have an API and support the POST operation only because of URL length limitations and the passing of complex parameters in the request, can you still say that you have a RESTful architecture? What the above basically implies is that for this particular (read-only) API, there is no semantic difference between a GET and a POST, so what can be done with a GET can also be done with a POST (but not vice versa due to the limitations). Would this still make the style of the architecture a RESTful one? Technically you are not violating any constraints. However you are severely reducing the self

I'm seeing a good bit of hand-waving on the subject of how to update only part of a resource (eg. status indicator) using REST. The options seem to be: Complain that HTTP doesn't have a PATCH or MODIFY command. However, the accepted answer on HTTP MODIFY verb for REST? does a good job of showing why that's not as good an idea as it might seem. Use POST with parameters and identify a method (eg. a parameter named "action"). Some suggestions are to specify an X-HTTP-Method-Override header with a self-defined method name. That seems to lead to the ugliness of switching within the implementation

I've read the w3.org spec on the 'HEAD' verb , and I guess I'm missing something. I can't see how it would be useful. Is the HTTP 'HEAD' verb useful in web development? If so, how? From RFC2616 : This method (HEAD) can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification. The reason why HEAD is preferred to GET is due to the absence of the message body in the response making it using in scenarios where you want to

I can't seem to receive HTTP OPTIONS requests in my IIS6 hosted ASP.NET application. I'm testing it using a debug breakpoint (and file-log) in my Global.asax 's Application_BeginRequest method. The breakpoint is never hit and the client gets a HTTP 403 Forbidden, I'm assuming from IIS6 directly ( GET s and POST s work fine btw). I've tried several things in the web.config , including adding the following line to either and both the <system.webServer><handlers> and <system.web><httpHandlers> sections. <add name="OptionsHandler" verb="OPTIONS" path="*" type="System.Web.DefaultHttpHandler"/> I've

I'm currently getting the info about the files with GET, will it be faster if I rewrite it using HEAD request? Cause I close the connection after the first response. A HEAD response only includes the HTTP headers but no body - it is generally faster to just use a HEAD if you do not use any information in the body that would have normally transferred in a GET response - if there was no body to begin with it should not make a difference. Also from here : The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the