Hi, In netty-http implementation all JAX-RS resource classes had to implement HttpHandler interface. This is a burden to JAX-RS resource class developers. In our implementation we removed that coupling and made it optional to implement HttpHandler interface thinking of developers who would need the support of the methods provided by HttpHandler.
In netty-http all resource methods had to have HttpRequest and HttpResponder as the first two parameters which is an unwanted complexity. Several reasons for this were, - In netty-http there was no way to send HTTP responses from resource classes unless we have a reference to HttpResponder object. netty-http does not support returning objects from resource methods to send HTTP responses. - HttpRequest object is required to handle beyond basic requests such as file uploads. In our JAX-RS runtime we removed the mandatory requirement to have the above two parameters and implemented the support for returning POJO from the resource methods to send HTTP responses. With this approach of sending HTTP responses, the requirement of javax.ws.rs.core.Response type arises in order to customize the properties of the HTTP response such as HTTP status codes, HTTP headers etc. The default implementation for javax.ws.rs.core.Response is coming from jersey. But we cannot afford to have a jersey dependency. Therefore, our own javax.ws.rs.core.Response implementation was added to our JAX-RS runtime. With the above supports @Context annotation support was also implemented to inject HttpRequest and HttpResponder (currently supported) or other objects if someone needs them for additional operations. In our JAX-RS runtime, we implemented the support for @Produce, @Consume annotations in parallel to the POJO - request/response body mapping support. Currently request body -> POJO and POJO -> response body mapping is supported for xml and json requests/responses. With this the JAX-RS runtime can map endpoints to resource methods by considering the media types in HTTP request and @Produce, @Consume values of resource methods. Also, the runtime has the ability to respond to requests with appropriate status codes without the knowledge of resource methods in occasions such as the requested media type is unsupported, invalid request body etc. Best Regards, Samiyuru -- Samiyuru Senarathne *Software Engineer* Mobile : +94 (0) 71 134 6087 [email protected]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
