Hi Nuwan, In that case also HTTP 405 method not allowed will be responded by the framework.
Best Regards, Samiyuru On Mon, Dec 7, 2015 at 4:48 PM, Nuwan Pallewela <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> wrote: >> >>> Hi Samiyuru, >>> >>> See the commented line. >>> >>> On Thu, Oct 15, 2015 at 2:02 PM, Samiyuru Senarathne <[email protected]> >>> 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 >>>> [email protected] >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> 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 *[email protected] <[email protected]>* >>> Mobile *+94719079739 <%2B94719079739>@* >>> >>> >>> >> >> >> -- >> Samiyuru Senarathne >> *Software Engineer* >> Mobile : +94 (0) 71 134 6087 >> [email protected] >> > > > > -- > ---------------------------------------------------------- > > *Nuwan Chamara Pallewela* > > > *Software Engineer* > > *WSO2, Inc. *http://wso2.com > *lean . enterprise . middleware* > > Email *[email protected] <[email protected]>* > Mobile *+94719079739 <%2B94719079739>@* > > > -- 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
