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 : ruw...@wso2.com 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 <rasi...@wso2.com> 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 <ge...@wso2.com> wrote: > >> >> >> On Wed, Jun 15, 2016 at 10:11 AM, Ayyoob Hamza <ayy...@wso2.com> 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: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495> >>> >>> On Wed, Jun 15, 2016 at 8:47 AM, Rasika Perera <rasi...@wso2.com> 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 < >>>> dil...@wso2.com> 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 <sachi...@wso2.com> >>>>> 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 <hars...@wso2.com> >>>>>> wrote: >>>>>> >>>>>>> +1 >>>>>>> >>>>>>> Harshan Liyanage >>>>>>> Senior Software Engineer >>>>>>> Mobile: *+94724423048* >>>>>>> Email: hars...@wso2.com >>>>>>> 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 <ge...@wso2.com> >>>>>>> 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: ge...@wso2.com >>>>>>>> phone:(+94) 777911226 >>>>>>>> >>>>>>>> On Tue, Jun 14, 2016 at 11:48 PM, Harshan Liyanage < >>>>>>>> hars...@wso2.com> 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: hars...@wso2.com >>>>>>>>> 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 <ge...@wso2.com >>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> Hi Ayyoob >>>>>>>>>> >>>>>>>>>> On Tue, Jun 14, 2016 at 11:01 PM, Ayyoob Hamza <ayy...@wso2.com> >>>>>>>>>> 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: rasi...@wso2.com >>>> 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: rasi...@wso2.com > LinkedIn: http://lk.linkedin.com/in/rasika90 > > WSO2 Inc. www.wso2.com > lean.enterprise.middleware >
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
