I like the idea. Some comments:
1) There's some statuses that do not allow for a response body, IIRC HTTP 204. How would you handle that? Compile-time error? Other checks? 2) If for any reason, my server resource class redefines one of those exceptions, how would this be handled? I'd expect the one redefined on my server resource is used... May add more comments/ideas later... Thanks. On Thu, Jun 5, 2014 at 7:20 PM, Jerome Louvel <[email protected]> wrote: > Hi all, > > In V2.3 of Restlet API, we would like to introduce automatic conversion > between Java throwable and HTTP status+body, working both ways (client and > server sides). > > The goal is to be able to write annotated Java interfaces including > methods such as: > > @Get > public MyBean represent() throws MyServerError, MyNotFoundError; > > Were the MyServerError and MyNotFoundError could be serialized as > JSON/XML/eetc. error representations. For this you would annotate those > Throwable classes with a @Status annotation such as: > > @Status("500") > public class MyServerError implements Throwable{ > ... > } > > @Status("404") > public class MyNotFoundError extends RuntimeException{ > ... > } > > A ClientResource wrapped proxy of MyResource including the represent() > method would automatically deserialize the error JSON/XML/etc. into the > proper Java exception. > > A ServerResource implementing the MyResource would be able to directly > throw a MyServerError or a MyNotFoundError, setting its properties without > having to worry about the HTTP status and error body. Content negotiation > would even be able to take place. > > Would that be useful in your web APIs? Any design feed-back? > > Thanks, > Jerome > -- > http://restlet.com > @jlouvel <http://twitter.com/#!/jlouvel> > > > > > -- Fabián Mandelbaum IS Engineer ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3079972
