0

I am writing a REST application and i am using RESTLET. My service has a PUT method. As part of the response, i would like to return to the user Custom Status.

For Example :

200 - Successfully Created and Data processing in progress.

I tried to set the statuses as below.

@Put
public String storeItem(Representation entity) throws Exception {

// Some Processing

Status st = new Status(420,null,"REASON_PHRASE","Some description",null);           
setStatus(st);

return "Some String Representation"
}

When i try to access the URL using CURL, i get the following status line.

curl -v  -X PUT "http://localhost:8080/extensible/data/process" 
* About to connect() to localhost port 8080 (#0)
*   Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
> PUT /extensible/data/upload HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: localhost:8080
> Accept: */*
> 
< HTTP/1.1 420 420
< Content-Type: application/json; charset=UTF-8
< Date: Wed, 22 Jan 2014 06:56:24 GMT
< Accept-Ranges: bytes
< Server: Restlet-Framework/2.0.1
< Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
< Content-Length: 21
< 
* Connection #0 to host localhost left intact
* Closing connection #0

The status line above is HTTP/1.1 420 420 but i expect a status line of HTTP/1.1 420 REASON_PHRASE

What am i doing wrong? Any help will be greatly appreciated.

Dinesh
  • 31
  • 2
  • 7
  • Thanks for reporting this issue. I guess you are using the jetty connector, and I've just fixed the bug you mention in branches 2.1 (future release 2.1.7) and 2.2 (future release 2.2m7). The proposed workaround is to use the extension org.restlet.ext.simple, instead of org.restlet.ext.jetty. This extension correctly set the reason phrase. – Thierry Boileau Jan 23 '14 at 17:35

1 Answers1

0

My two cents about the design.
1. I think you need a pretty good reason to use a custom http status.
I don't think this is the case.
REST API consumed by applications and the application that consume the API know that this particular PUT is part of an asynchronous process.
There for a simple 200 with the new id as data or link to the edit url should be enough. The client application should notify the user, if decided to do so.

  1. If you still think a custom status is the right way you should consider using 20* and not 420.
ZAky
  • 1,209
  • 8
  • 22
  • Hi, Custom failure message does not give much information about the service i am designing, even if the body has the whole error message. So i am more inclined towards custom messages. 420 is just an example. – Dinesh Jan 27 '14 at 12:02