Thanks Fabian for the feed-back. 1) We would not set the response entity in this case, only the HTTP status would be set on the response based on the annotation value.
2) I'm not 100% clear about the scenario. Let me try some replies: a) if you do not throw any exception and manually set an error status and response entity, then it would take precedence b) the goal is for your resource classes to actually define those exceptions and ensure they are automatically handled at run-time. c) we might want to offer some generic exceptions such as NotFoundException<T> based on @Status for main HTTP status codes that would let you override them to specify a custom <T> bean to serialize as response entity but the HTTP status code would be automatically set. Thanks, Jerome -- http://restlet.com @jlouvel <http://twitter.com/#!/jlouvel> On Thu, Jun 5, 2014 at 3:52 PM, Fabian Mandelbaum <[email protected]> wrote: > 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=3079973
