It is explicitly mentioned here in the [RFC](http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.7/)

The short answer is:

You **should include** a response body with an entity describing the deleted item/resource if you return **200**.

**202** is something like an asynchronous request/response return status. 

**204** says explicitly that you do not include a response body

Yes, you should usually respond with a 200 response code as per [the W3C spec][1]:

&gt; 9.7 DELETE
&gt; 
&gt; The DELETE method requests that the
&gt; origin server delete the resource
&gt; identified by the Request-URI. This
&gt; method MAY be overridden by human
&gt; intervention (or other means) on the
&gt; origin server. The client cannot be
&gt; guaranteed that the operation has been
&gt; carried out, even if the status code
&gt; returned from the origin server
&gt; indicates that the action has been
&gt; completed successfully. However, the
&gt; server SHOULD NOT indicate success
&gt; unless, at the time the response is
&gt; given, it intends to delete the
&gt; resource or move it to an inaccessible
&gt; location.
&gt; 
&gt; A successful response SHOULD be 200
&gt; (OK) if the response includes an
&gt; entity describing the status, 202
&gt; (Accepted) if the action has not yet
&gt; been enacted, or 204 (No Content) if
&gt; the action has been enacted but the
&gt; response does not include an entity.
&gt; 
&gt; If the request passes through a cache
&gt; and the Request-URI identifies one or
&gt; more currently cached entities, those
&gt; entries SHOULD be treated as stale.
&gt; Responses to this method are not
&gt; cacheable.


  [1]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Is there a function to chomp last character in the string if it&#39;s some special character? For example, I need to remove backslash if it&#39;s there, and do nothing, if not. I know I can do it with regex easily, but wonder if there something like a small built-in function for that.

Remove last character if it&#39;s a backslash

What&#39;s the benefit of setting an alias for an action method using the &quot;ActionName&quot; attribute? I really don&#39;t see much benefit of it, in providing the user the option to call an action method with some other name. After specifying the alias, the user is able to call the action method only using the alias. But if that is required then why doesn&#39;t the user change the name of the action method rather then specifying an alias for it?

I would really appreciate if anyone can provide me an example of the use of &quot;ActionName&quot; in a scenario where it can provide great benefit or it is best to use.  

Purpose of ActionName

I assume the response code 200 always allows for a response-body, but I can&#39;t find any explicit mention of response-bodies for DELETE-requests. 

Is a response-body allowed for a HTTP-DELETE-request?

<p>I assume the response code 200 always allows for a response-body, but I can't find any explicit mention of response-bodies for DELETE-requests.</p>


I&#39;m writing a RESTful API module for an application in PHP, and I&#39;m a bit mixed on the verbs `HEAD` and `OPTIONS`.

&gt; - `OPTIONS&#160;` Used to retrieve the available HTTP verbs for a given resource?
&gt; - `HEAD`     Used to determine whether a given resource is available?

If someone could clarify* these verbs, that would be much appreciated.

&lt;sub&gt;* The clarification was with respect to RESTful API architectures re-purposing HTTP verbs. I&#39;ve since come to the realization that both `HEAD` and `OPTIONS` should *not* be re-purposed, and instead behave predictably as any HTTP application should. Oh, how we grow in 2 years.&lt;/sub&gt;

RESTful API methods; HEAD &amp; OPTIONS

I have an application whose primary function works in real time, through websockets or long polling.

However, most of the site is written in a RESTful fashion, which is nice for application s and other clients in the future. However, I&#39;m thinking about transitioning to a websocket API for all site functions, away from REST. That would make it easier for me to integrate real time features into all parts of the site. Would this make it more difficult to build applications or mobile clients?

I found that some people are already doing stuff like this: [SocketStream][1]

  [1]: https://github.com/socketstream/socketstream



Websocket API to replace REST API?

I&#39;m new to REST and I&#39;ve observed that in some RESTful services they use different resource URI for update/get/delete and Create. Such as

 - Create - using ***/resources*** with POST method (observe plural) at some places using ***/resource*** (singular)
 - Update - using ***/resource/123*** with PUT method
 - Get - Using ***/resource/123*** with GET method


I&#39;m little bit confused about this URI naming convention. What should we use plural or singular for resource creation? What should be the criteria while deciding that?

Should I use Singular or Plural name convention for REST resources?

What is the &quot;RESTful&quot; way of adding non-CRUD operations to a RESTful service?  Say I have a service that allows CRUD access to records like this:

    GET /api/car/123           &lt;- Returns information for the Car object with ID 123
    POST /api/car              &lt;- Creates a new car (with properties in the request)
    PUT /api/car/123           &lt;- Updates car 123 (with properties in the request)
    DELETE /api/car/123        &lt;- Deletes car 123    
    POST /api/car/123/wheel/   &lt;- Creates a wheel and associates it to car 123

If I want to change the car&#39;s color, I would simply `POST /api/car/123` and include a POST variable for the new color.

But let&#39;s say I want to purchase a car, and that operation is more complicated than simply updating a &quot;user&quot; record&#39;s &quot;owned car&quot; property.  Is it RESTful to simply do something like `POST /api/car/123/purchase`, where &quot;purchase&quot; is essentially a method name?  Or should I use a custom HTTP verb, like `PURCHASE` instead of `POST`?

Or are non-CRUD operations completely outside the scope of REST?

Non-CRUD operations in a RESTful service

Sorry, this questions sounds silly, but after developing some of my RESTful services using Jersey, I asked myself the question -- If REST is just an architecture, and not a protocol like SOAP, why do we need a specification like JAX-RS?

I actually googled for questions like &quot;What is the difference between servlets and RESTful services over HTTP&quot; and to sum up the community answers, I got:

1. RESTful service development (on Jersey) is an architecture, which inherently uses servlets.
2. JAX-RS compliant tools like Jersey provide easy marshalling-unmarshalling of XML/JSON data, helping the developers.
3. REST helps us use GET/POST/PUT/DELETE in a fashion that is far efficient than normal servlets.

According to these answers, I guess if I write a servlet which uses JAXB (for dealing with automatic serialization), and I efficiently use GET/POST/PUT/DELETE in my servlet code, I don&#39;t use a tool like Jersey, and hence JAX-RS.

I know I am terribly wrong passing this statement, please correct me.

PS: This doubt actually came in when I had to develop some RESTful services in PHP. After going on through some of the RESTful PHP codes, I realized they are just the same old PHP scripts, with some helper methods for handling XML/JSON.



Why use JAX-RS / Jersey?

I&#39;m POSTing data to an external API (using PHP, if it&#39;s relevant). 

Should I URL-encode the POST variables that I pass?

Or do I only need to URL-encode GET data?

---

UPDATE: This is my PHP, in case it is relevant: 

	$fields = array(
	    &#39;mediaupload&#39;=&gt;$file_field,
	    &#39;username&#39;=&gt;urlencode($_POST[&quot;username&quot;]),
	    &#39;password&#39;=&gt;urlencode($_POST[&quot;password&quot;]),
	    &#39;latitude&#39;=&gt;urlencode($_POST[&quot;latitude&quot;]),
	    &#39;longitude&#39;=&gt;urlencode($_POST[&quot;longitude&quot;]),
	    &#39;datetime&#39;=&gt;urlencode($_POST[&quot;datetime&quot;]),
	    &#39;category&#39;=&gt;urlencode($_POST[&quot;category&quot;]),
	    &#39;metacategory&#39;=&gt;urlencode($_POST[&quot;metacategory&quot;]),
	    &#39;caption&#39;=&gt;($_POST[&quot;description&quot;])
	);
	$fields_string = http_build_query($fields);
	$ch = curl_init();
	curl_setopt($ch, CURLOPT_URL,$url);
	curl_setopt($ch,CURLOPT_POST,count($fields));
    curl_setopt($ch,CURLOPT_POSTFIELDS,$fields);
	curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
	$response = curl_exec($ch);

Should I URL-encode POST data?

I&#39;m trying to issue a GET command to my local server using `netcat` by doing the following:

    echo -e &quot;GET / HTTP/1.1\nHost: localhost&quot; | nc localhost 80

Unfortunately, I get a `HTTP/1.1 400 Bad Request` response for this. What, at the very minimum, is required for a HTTP request? 

What, at the bare minimum, is required for an HTTP request?

When using http basic authentication, the username can be passed in the URL, e.g.

    http://david@foo.com/path/

But now suppose the username is an email address, e.g. david@company.com. Doing this is clearly ambiguous:

    http://david@company.com@foo.com/path/

Is there a way to escape the @ character in the username? I tried standard URL encoding:

    http://david%40company.com@foo.com/path/

But that didn&#39;t do it.

Escaping username characters in basic auth URLs

Is it a way to remove or hide http referer information in request header? 
i want to remove http referrer information of users who goes to other site from my site using a script possibly in javascript python or django

example:

    Host	slogout.espncricinfo.com
    User-Agent	Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0    
    Accept	text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8    
    Accept-Language	en-us,en;q=0.5    
    Accept-Encoding	gzip, deflate    
    Accept-Charset	ISO-8859-1,utf-8;q=0.7,*;q=0.7    
    Connection	keep-alive
    Referer	http://slogout.espncricinfo.com/index.php?page=index&amp;level=login



Remove http referer

It is a fairly common requirement to support undeletes or delayed/batched deletions for data services. What I&#39;m wondering is how to implement this in a RESTful way. I&#39;m torn between a few different options (none of which seems terribly attractive to me). Common across these different options, I believe, is the need for an API which returns all resource marked as deleted for a particular resource type.

Here are some options I&#39;ve thought about and some of their pros/cons:

Options to mark resource as deleted:

 -  Use HTTP DELETE to mark the resource as deleted.
 -  Use HTTP PUT/POST to update deleted flag. This doesn&#39;t feel right since it maps what is essentially a deletion away from the HTTP DELETE method and into other HTTP methods.

Options when GET-ing resource marked for deletion:

 -  Return HTTP Status 404 for a resource marked as deleted. Clean &amp; transparent, but how do we tell the difference between a resource that is really deleted vs. one just marked as deleted.
 -  Return HTTP Status 410. Provides way to tell the difference, but 410 technically says it &quot;is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval.&quot; There may be enough wiggle room in the words &quot;expected&quot; and &quot;SHOULD&quot; here. Not sure how well 410 is supported/understood out there in clients.
 -  Return HTTP Status 200 and include flag field indicating resource is deleted. This seems wierd since the idea of deleting it in the first place was because you actually wanted it to not appear. This pushes responsibility for filtering out deleted resources down to clients.

Options for responses which include this deleted resource:

 -  Omit the resources makred as deleted. Clean &amp; simple. But what if you actually want to know about deleted resources.
 -  Include them along with field indicating that they are deleted. This pushes responsibility for filtering out deleted resources down to clients. It makes pagination tricky if you want to only page through active or deleted resources.

Options when updating a resource marked for deletion:

 -  Use HTTP Status 404. The resource is gone right? But, how can you tell the difference between a resource marked as deleted and one actually deleted. HTTP body in 404 response could disambiguate here but then clients are left with parsing/interpreting your body to disambiguate. Maybe response header might help here? Which one? Custom header?
 -  Use HTTP Status 409 with message about how resource must first be undeleted.

Options to undelete resource marked for deletion:

 -  Use HTTP PUT/POST for update operation of resource and mark it as active again. This only works as long as you&#39;re not returning an HTTP 404 for the GET operation for the resource since it doesn&#39;t make since to PUT/POST to a resource that is &quot;Not found&quot; (404).
 -  Use HTTP PUT/POST for creation operation of resource. The problem here is which data takes precedence? The data sent up in the create operation? Or the data that is being undeleted? filter it out of any other queries that would have returned it. Then, treat the HTTP PUT/POST that creates the resource as an undelete if the resource identifier points to a resource marked as deleted.
 -  Separate REST path dedicated to undelete resources marked for deletion.

This is by no means an exhaustive list. I just wanted to enumerate some of the options that have been bouncing around in my head.

I know the answer to how to do this is, as usual, &quot;it depends&quot;. What I&#39;m curious about is what qualifications/requirements would you use to make your decision? How have you seen this implemented or implemented it yourself?

RESTful undelete

I use HTTP `PUT` and `DELETE` in my ASP.NET MVC3 application. When I run it in local, every thing works correctly; But when I publish the application to the server, these methods do not work. 

Are there any special settings for enable a web server to support `PUT` and `DELETE` requests? I&#39;m using shared hosting with IIS 7.5.

**UPDATE:**

I enable `PUT` and `DELETE` requests in `IIS manager`. `PUT` command work fine. But `DELETE` still not works. I create requests by `jQuery`:

I&#39;m in this page:

    http://domain.com/dashboard/edit-site/103323/links/

and my ajax call is:

    $.ajax({
        // url: same as page-url,
        cache: false,
        type: &#39;DELETE&#39;,
        data: { linkid: $(link).data(&quot;linkid&quot;) },
        beforeSend: function () {
            // doing something in UI
        },
        complete: function () {
            // doing something in UI
        },
        success: function (data) {
            // doing something in UI
        },
        error: function () {
            // doing something in UI
        }
    });

This will create a request like this:

    Accept: */*
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    Origin: http://domain.com
    Referer: http://domain.com/dashboard/edit-site/103323/links/
    User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1
    X-Requested-With: XMLHttpRequest

With this **`Form Data`**:

    linkid:104044

How do I enable HTTP PUT and DELETE for ASP.NET MVC in IIS?

I’m trying to make a request using CURL like this:

    curl -X DELETE &quot;https://myhost/context/path/users/OXYugGKg207g5uN/07V&quot; 

where `OXYugGKg207g5uN/07V` is a hash, so I suppose that I need to encode before do this request.

I have tried `curl -X DELETE --data-urlenconded &quot;https://myhost/context/path/users/OXYugGKg207g5uN/07V&quot;` 

Some ideas?

DELETE using CURL with encoded URL

### Introduction ###

I&#39;ve read the following:

&gt; Hypertext Transfer Protocol (HTTP) is the life of the web. It&#39;s used every time you transfer a document, or make an AJAX request. But HTTP is surprisingly a relative unknown among some web developers.
&gt;
&gt; The HTTP verbs comprise a major portion of our “uniform interface” constraint and provide us the action counterpart to the noun-based resource. The primary or most-commonly-used HTTP verbs (or methods, as they are properly called) are POST, GET, **PUT**, and **DELETE**.

### Huh? ###

Well, we came to the point I lost track of things.

`PUT` and `DELETE`, they say. I&#39;ve only ever heard of `POST` and `GET` and never saw something like `$_PUT` or `$_DELETE` passing by in any PHP code I&#39;ve ever viewed.

### My question ###

What are these methods (PUT) and (DELETE) for and if it&#39;s possible to use them in PHP, how would I go about this.

**Note:** I know this is not really a problem but I always grab a learning opportunity if I see one and would very much like to learn to use these methods in PHP if this is possible.

HTTP protocol&#39;s PUT and DELETE and their usage in PHP

I&#39;m trying to talk to a somewhat RESTful API from an Angular 2 frontend.

To remove some item from a collection, I need to send some other data in addition to the remov&#233;e unique id(that can be appended to the url), namely an authentication token, some collection info and some ancilliary data.

The most straightforward way I&#39;ve found to do so is putting the authentication token in the request Headers, and other data in the body.

However, the Http module of Angular 2 doesn&#39;t quite approve of a DELETE request with a body, and trying to make this request

&lt;!-- language: lang-js --&gt;

    let headers= new Headers();
	headers.append(&#39;access-token&#39;, token);
	   
	let body= JSON.stringify({
        target: targetId,
        subset: &quot;fruits&quot;,
        reason: &quot;rotten&quot;
    });

	let options= new RequestOptions({headers:headers});
    this.http.delete(&#39;http://testAPI:3000/stuff&#39;, body,options).subscribe((ok)=&gt;{console.log(ok)}); &lt;------line 67

gives this error

    app/services/test.service.ts(67,4): error TS2346: Supplied parameters do not match any signature of call target.

Now, am I doing something wrong syntax-wise? I&#39;m pretty sure a DELETE body is supported per RFC

Are there better ways to send that data?

Or should I just dump it in headers and call it a day?

Any insight on this conundrum would be appreciated

Content Type	Original Author	Original Content on Stackoverflow
Question	scrrr	View Question on Stackoverflow
Solution 1 - Rest	fyr	View Answer on Stackoverflow
Solution 2 - Rest	Brian Scott	View Answer on Stackoverflow

Is a response-body allowed for a HTTP-DELETE-request?

Rest Problem Overview

Rest Solutions

Solution 1 - Rest

Solution 2 - Rest

Purpose of ActionName

Remove last character if it's a backslash

Attributions