Yes
Take an API like /devices and if there are no records in it, return an
empty array. In this case the collection there is empty but it does exist.
So we cannot return 404 and use 200 instead.
If it is an single resource like devices/{deviceId} and if it is not found
return 404, because it does not exist.
On Wed, Jun 15, 2016 at 11:42 AM, Ruwan Yatawara <ruw...@wso2.com> wrote:
> 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 : 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:26 AM, Ruwan Yatawara <ruw...@wso2.com> 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 : 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
>>>
>>
>>
>
--
Regards,
Chatura Dilan Perera
*Associate Tech Lead** - WSO2 Inc.*
www.dilan.me
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
