http-method

I am developing REST WCF service and As theoretically i know when to opt for what purpose. GET to get the resource PUT to update POST to Insert DELETE to delete But what is the disadvantage if we don't follow this above rule, suppose to insert a record i used GET method? Giuseppe Romagnuolo Because the HTTP GET method is specified as idempotent, a GET request, by specification, can be resubmitted with the assumption that it will not change anything on the server. This is not the case for a HTTP POST which by specification can change the status of the application running on the server. So, by

Curl offers a series of different http method calls that are prefixed with a X, but also offers the same methods without. I've tried both and I can't seem to figure out the difference. Can someone explain to me quickly how these two operations differ? By default you use curl without explicitly saying which request method to use. If you just pass in a HTTP URL like curl http://example.com it will use GET. If you use -d or -F curl will use POST, -I will cause a HEAD and -T will make it a PUT. If for whatever reason you're not happy with these default choices that curl does for you, you can

I want to design my rest endpoint with the appropriate method for the following scenario. There is a group. Each group has a status. The group can be activated or inactivated by the admin. Should I design my end point as PUT /groups/api/v1/groups/{group id}/status/activate OR PATCH /groups/api/v1/groups/{group id} with request body like {action:activate|deactivate} Luke Peterson The PATCH method is the correct choice here as you're updating an existing resource - the group ID. PUT should only be used if you're replacing a resource in its entirety. Further information on partial resource

I was reading the spec on CORS requests, and I found this about preflight requests: These are requests to a non same origin URL with an HTTP request method other than GET that first need to be authorized using either a preflight result cache entry or a preflight request. I had thought the purpose of preflight requests was to check whether a request was allowed before making it, in case it (illegitimately) changed server state . But HEAD and OPTIONS don't modify server state. I must misunderstand the reason for preflight check. What is the purpose (aka the reason, motivation, or rationale) for

While the HTTP 1.1 spec seems to allow message bodies on DELETE requests, it seems to indicate that servers should ignore it since there are no defined semantics for it. 4.3 Message Body A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request. I've already reviewed several related discussions on this topic on SO and beyond, such as: Is an entity body allowed for an HTTP DELETE request? Payloads of HTTP Request Methods HTTP GET with request body

The Wikipedia entry on HTTP lists the following HTTP request methods: HEAD: Asks for the response identical to the one that would correspond to a GET request, but without the response body. GET: Requests a representation of the specified resource. POST: Submits data to be processed (e.g., from an HTML form) to the identified resource. The data is included in the body of the request. PUT: Uploads a representation of the specified resource. DELETE: Deletes the specified resource. TRACE: Echoes back the received request, so that a client can see what (if any) changes or additions have been made

In RESTful style programming, we should use HTTP methods as our building blocks. I'm a little confused though which methods match up to the classic CRUD methods. GET/Read and DELETE/Delete are obvious enough. However, what is the difference between PUT/POST? Do they match one to one with Create and Update? Create = PUT with a new URI POST to a base URI returning a newly created URI Read = GET Update = PUT with an existing URI Delete = DELETE PUT can map to both Create and Update depending on the existence of the URI used with the PUT. POST maps to Create. Correction: POST can also map to