Hi Samiyuru, That is really good. Thanks for the explanation.
What would happen if user implement a service with unsupported http methods? What will be the response when client sends a request for unsupported http method resource? Can we give an error message in the deploy time? Thanks, Nuwan On Mon, Dec 7, 2015 at 10:04 AM, Samiyuru Senarathne <samiy...@wso2.com> wrote: > Hi Nuwan, > > For unavailable HTTP methods for an existing path of a resource class, we > respond with HTTP 405 method not allowed. This is same for unsupported HTTP > methods by the framework (IE. PATCH, HEAD, etc.) as well as the unsupported > HTTP methods by the resource class (IE. POST request is made to a resource > method where only @GET is specified). For these two cases, a > differentiation was not made because in the client's perspective both are > same. > > Note: When a request is made to a path that is not available in a resource > class, the response is 404 not found. > > Best Regards, > Samiyuru > > On Sun, Dec 6, 2015 at 6:01 PM, Nuwan Pallewela <nuw...@wso2.com> wrote: > >> Hi Samiyuru, >> >> See the commented line. >> >> On Thu, Oct 15, 2015 at 2:02 PM, Samiyuru Senarathne <samiy...@wso2.com> >> wrote: >> >>> 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. >>> >> >> Are we responding likewise for invalid requests with unsupported HTTP >> method types? >> Since we only support sub set of HTTP methods, it would be nice to have >> appropriate status codes responses for unsupported HTTP methods too. >> >>> >>> >>> Best Regards, >>> Samiyuru >>> -- >>> Samiyuru Senarathne >>> *Software Engineer* >>> Mobile : +94 (0) 71 134 6087 >>> samiy...@wso2.com >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> Thanks, >> Nuwan >> >> -- >> ---------------------------------------------------------- >> >> *Nuwan Chamara Pallewela* >> >> >> *Software Engineer* >> >> *WSO2, Inc. *http://wso2.com >> *lean . enterprise . middleware* >> >> Email *nuw...@wso2.com <nuw...@wso2.com>* >> Mobile *+94719079739 <%2B94719079739>@* >> >> >> > > > -- > Samiyuru Senarathne > *Software Engineer* > Mobile : +94 (0) 71 134 6087 > samiy...@wso2.com > -- ---------------------------------------------------------- *Nuwan Chamara Pallewela* *Software Engineer* *WSO2, Inc. *http://wso2.com *lean . enterprise . middleware* Email *nuw...@wso2.com <nuw...@wso2.com>* Mobile *+94719079739@*
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
