Hello Jerome, answering between lines:
On Thu, Jun 5, 2014 at 8:15 PM, Jerome Louvel <[email protected]> wrote: > 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. > > OK > 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. > > Well, a) and c) (mostly c) is what I had in mind, so we agree :-) > Thanks, > My pleasure. > 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 >> > > -- Fabián Mandelbaum IS Engineer ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3079994
