However, as per the implementation, since what is drawn from '/devices' is a list of resources.. and not an individual device. I believe a 200 ok with an empty set is acceptable.
Thanks and Regards, Ruwan Yatawara Associate Technical Lead, WSO2 Inc. email : [email protected] mobile : +94 77 9110413 blog : http://ruwansrants.blogspot.com/ https://500px.com/ruwan_ace www: :http://wso2.com On Wed, Jun 15, 2016 at 11:26 AM, Ruwan Yatawara <[email protected]> wrote: > In the devices example that's used, it is my opinion that the device that > you are trying to locate is the resource, "/devices" is merely the context. > Therefore if a resource cannot be located a 404 no content is acceptable. > However, when looking at things from a AJAX request perspective, this kind > of scenario become tricky to handle. > > Even when I started on working on the UI stabilisation effort, i thought > 204 was the way to go, however upon further reading and looking at things > from aforementioned perspective, IMHO 404 seems the right response to > return when a resource is not found. > > Thanks and Regards, > > Ruwan Yatawara > > Associate Technical Lead, > WSO2 Inc. > > email : [email protected] > mobile : +94 77 9110413 > blog : http://ruwansrants.blogspot.com/ > https://500px.com/ruwan_ace > www: :http://wso2.com > > > On Wed, Jun 15, 2016 at 11:15 AM, Rasika Perera <[email protected]> wrote: > >> Hi All, >> >> >> >>> I think that even though it is a single resource or a collection it >>> should not be handled differently. if there is no resource behind the URI >>> then it should be 404. >> >> -1. "/devices" is your resource in this case. and it is a *collection*. >> Query components are for retrieval of non-hierarchical data >> . You should not use the query string to identify a *single* resource. >> "?type={platform}" is not a part of your resources hierarchy. Hence >> returning 404 may convey that "/devices" is non-existant and client should >> not try "/devices" on proceeding requests. >> >> Thanks, >> Rasika >> >> >> >> On Wed, Jun 15, 2016 at 10:51 AM, Geeth Munasinghe <[email protected]> >> wrote: >> >>> >>> >>> On Wed, Jun 15, 2016 at 10:11 AM, Ayyoob Hamza <[email protected]> wrote: >>> >>>> I think that even though it is a single resource or a collection it >>>> should not be handled differently. if there is no resource behind the URI >>>> then it should be 404. >>>> >>> -1, >>> AFAIK, it is an actual endpoint (URL) refers to a resource. (In case of >>> "/devices?{query_params}", "/devices" is the resource) It does not matter >>> that resource returns an output or not. Because resource can return an >>> empty body for a request which in my opinion a valid response. Furthermore >>> returning a empty body does not mean that resource is not found (404) (in >>> case of /devices, it is there) or client has made an error with the >>> request. Empty body means that no records available in database matching >>> the filtering criteria. 404 implies a wrong message to the client, which >>> means that he has done something wrong with the request. If we send 404 for >>> empty body (returns due to no records in the database), then later same >>> request will behave differently when database has relevant data. In my >>> opinion, it should return 200 for empty body. >>> >>> According to [1] 4XX is used for client side errors. >>> >>> [1] https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html >>> >>> Thanks >>> Geeth >>> >>>> >>>> However this could be subjective so have to delve into our rest >>>> guidelines to make a decision on it. >>>> >>>> [Adding Frank and Joe] >>>> >>>> *Ayyoob Hamza* >>>> *Software Engineer* >>>> WSO2 Inc.; http://wso2.com >>>> email: [email protected] cell: +94 77 1681010 <%2B94%2077%207779495> >>>> >>>> On Wed, Jun 15, 2016 at 8:47 AM, Rasika Perera <[email protected]> >>>> wrote: >>>> >>>>> For example, /devices/{device-id} is a URI. Hence, by the time client >>>>>> makes a request for a non-existing device id, that results in a URI that >>>>>> could not be found and returning a 404 for that is perfectly valid. >>>>> >>>>> +1 >>>>> >>>>> But if we take an example like this, /devices?type={platform}, here >>>>>> the URI is /devices. If we return a 404 here at any instance, what it >>>>>> simply means is that the requested URI (/devices) could not be found in >>>>>> the >>>>>> server and should not be used anymore which is wrong. It's a >>>>>> defined resource collection that can exist in the server with 0 to many >>>>>> items. >>>>> >>>>> Yes, In this case, I prefer a empty list with HTTP 200 is more >>>>> intuitive and reduces complexities at the client side processing(i.e. >>>>> if-check for 204). >>>>> >>>>> The query component contains non-hierarchical data >>>>> . >>>>> "/devices" will give you all devices. >>>>> "/devices?type=non-existent-type" will return empty list of devices since >>>>> no matching device exist. Simply your filtering criteria haven't met any >>>>> device. >>>>> >>>>> On Wed, Jun 15, 2016 at 7:22 AM, Dilan Udara Ariyaratne < >>>>> [email protected]> wrote: >>>>> >>>>>> I also think that Geeth is making a valid point here and it makes >>>>>> sense in practice. >>>>>> >>>>>> According to the w3c specification on status codes, >>>>>> 4XX http status code range is totally reserved for client errors and >>>>>> 404 is specifically returned when the requested "URI" could not be found >>>>>> in >>>>>> the server. >>>>>> >>>>>> For example, /devices/{device-id} is a URI. Hence, by the time client >>>>>> makes a request for a non-existing device id, that results in a URI that >>>>>> could not be found and returning a 404 for that is perfectly valid. >>>>>> >>>>>> But if we take an example like this, /devices?type={platform}, here >>>>>> the URI is /devices. If we return a 404 here at any instance, what it >>>>>> simply means is that the requested URI (/devices) could not be found in >>>>>> the >>>>>> server and should not be used anymore which is wrong. It's a >>>>>> defined resource collection that can exist in the server with 0 to many >>>>>> items. >>>>>> >>>>>> Therefore, in such instances where we do not query for exact >>>>>> resources, but for a possible collection of resources in the server using >>>>>> query parameters, it's much better to return an empty set with a 200 >>>>>> rather >>>>>> than a 404 if there exist zero items by the time of request. >>>>>> >>>>>> Cheers, >>>>>> Dilan. >>>>>> >>>>>> On Wednesday, June 15, 2016, Kamidu Punchihewa <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> Agreed with Geeth and Harshan, When it come to the OOB User >>>>>>> interface of EMM the request with an 404 is detect as an error and your >>>>>>> is >>>>>>> prompted with an error message since the error handling is handling in a >>>>>>> Central controller witch acts in general so if there are no error >>>>>>> occurred >>>>>>> in the sever side best approach not to return status code in 400 - 499 >>>>>>> range. >>>>>>> >>>>>>> Thanks & Best Regards, >>>>>>> >>>>>>> Kamidu Sachith Punchihewa >>>>>>> *Software Engineer* >>>>>>> WSO2, Inc. >>>>>>> lean . enterprise . middleware >>>>>>> Mobile : +94 (0) 770566749 <%2B94%20%280%29%20773%20451194> >>>>>>> >>>>>>> >>>>>>> Disclaimer: This communication may contain privileged or other >>>>>>> confidential information and is intended exclusively for the >>>>>>> addressee/s. >>>>>>> If you are not the intended recipient/s, or believe that you may have >>>>>>> received this communication in error, please reply to the sender >>>>>>> indicating >>>>>>> that fact and delete the copy you received and in addition, you should >>>>>>> not >>>>>>> print, copy, retransmit, disseminate, or otherwise use the information >>>>>>> contained in this communication. Internet communications cannot be >>>>>>> guaranteed to be timely, secure, error or virus-free. The sender does >>>>>>> not >>>>>>> accept liability for any errors or omissions. >>>>>>> >>>>>>> On Wed, Jun 15, 2016 at 12:18 AM, Harshan Liyanage <[email protected] >>>>>>> > wrote: >>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>> Harshan Liyanage >>>>>>>> Senior Software Engineer >>>>>>>> Mobile: *+94724423048* >>>>>>>> Email: [email protected] >>>>>>>> Blog : http://harshanliyanage.blogspot.com/ >>>>>>>> *WSO2, Inc. :** wso2.com <http://wso2.com/>* >>>>>>>> lean.enterprise.middleware. >>>>>>>> >>>>>>>> On Tue, Jun 14, 2016 at 1:42 PM, Geeth Munasinghe <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I think we should make relevant changes in APIs to send 200 status >>>>>>>>> code for no content responses. This should only be done if the >>>>>>>>> request is >>>>>>>>> with query or form params, but not for request with path parameters >>>>>>>>> (Which >>>>>>>>> is an exact resource, should return 404). >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Geeth >>>>>>>>> >>>>>>>>> >>>>>>>>> *G. K. S. Munasinghe* >>>>>>>>> *Senior Software Engineer,* >>>>>>>>> *WSO2, Inc. http://wso2.com <http://wso2.com/> * >>>>>>>>> *lean.enterprise.middleware.* >>>>>>>>> >>>>>>>>> email: [email protected] >>>>>>>>> phone:(+94) 777911226 >>>>>>>>> >>>>>>>>> On Tue, Jun 14, 2016 at 11:48 PM, Harshan Liyanage < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi Geeth, >>>>>>>>>> >>>>>>>>>> Agreed. In such cases I guess sending 200 with empty body will be >>>>>>>>>> more appropriate because there are some cases where the server >>>>>>>>>> responds >>>>>>>>>> with 204 when the service does not return data (i.e in some DELETE, >>>>>>>>>> POST >>>>>>>>>> requests). >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Harshan Liyanage >>>>>>>>>> Senior Software Engineer >>>>>>>>>> Mobile: *+94724423048* >>>>>>>>>> Email: [email protected] >>>>>>>>>> Blog : http://harshanliyanage.blogspot.com/ >>>>>>>>>> *WSO2, Inc. :** wso2.com <http://wso2.com/>* >>>>>>>>>> lean.enterprise.middleware. >>>>>>>>>> >>>>>>>>>> On Tue, Jun 14, 2016 at 12:42 PM, Geeth Munasinghe < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Ayyoob >>>>>>>>>>> >>>>>>>>>>> On Tue, Jun 14, 2016 at 11:01 PM, Ayyoob Hamza <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Yes I agree with Harshan, >>>>>>>>>>>> >>>>>>>>>>>> It is a question about whether we are looking this as a >>>>>>>>>>>> resource or an endpoint. We should look at the url in the resource >>>>>>>>>>>> context(restful approach) even though it is built on top of http. >>>>>>>>>>>> Therefore >>>>>>>>>>>> IMO we need to think that we are mapping a resource to the url and >>>>>>>>>>>> therefore suitable response would be 404. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> /devices/{device_idenitifier} - this should return 404 if >>>>>>>>>>> requested for non-existence device. I have no argument about it. >>>>>>>>>>> But my >>>>>>>>>>> concern is at /devices?{query_parameter}. This is different. Actual >>>>>>>>>>> resource is /devices, but it returns no content due to filtering >>>>>>>>>>> criteria >>>>>>>>>>> associated with query parameters, That is, in my opinion is a valid >>>>>>>>>>> request >>>>>>>>>>> which deserves a 200 or 204 response code. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Geeth >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> *Dilan U. Ariyaratne* >>>>>> Senior Software Engineer >>>>>> WSO2 Inc. <http://wso2.com/> >>>>>> Mobile: +94766405580 <%2B94766405580> >>>>>> lean . enterprise . middleware >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> With Regards, >>>>> >>>>> *Rasika Perera* >>>>> Software Engineer >>>>> M: +94 71 680 9060 E: [email protected] >>>>> LinkedIn: http://lk.linkedin.com/in/rasika90 >>>>> >>>>> WSO2 Inc. www.wso2.com >>>>> lean.enterprise.middleware >>>>> >>>> >>>> >>> >> >> >> -- >> With Regards, >> >> *Rasika Perera* >> Software Engineer >> M: +94 71 680 9060 E: [email protected] >> LinkedIn: http://lk.linkedin.com/in/rasika90 >> >> WSO2 Inc. www.wso2.com >> lean.enterprise.middleware >> > >
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
