Re: [Dev] [EMM] Why we are using 404 for "No Content" responses ?

[Geeth Munasinghe]

On Tue, Jul 12, 2016 at 7:11 AM, Madhawa Gunasekara 
wrote:

> Hi All,
>
> Why can't we simply use 204 as status code for the No Content responses?
> because according to the spec all the 2xx status codes are successful.
> AFAIU We should use 204 for No Content responses.
>

AFAIK we send a empty json array ( "[]" ) when no records are available. So
it is not a No Content response.

>
> Thanks,
> Madhawa
>
> On Wed, Jun 15, 2016 at 7:40 PM, Manuranga Perera  wrote:
>
>> Seems like the bigger issue here is that resource collection is not being
>>  a path parameter.
>>
>> /devices/type=android -> not ideal, there is no good way to distinguish
>> non-existing types
>> /devices/android -> seems to be more REST like
>>
>> On Wed, Jun 15, 2016 at 5:17 AM, Joseph Fonseka  wrote:
>>
>>> Hi All
>>>
>>> In AM what we practice is that collection resource will return 200 Ok
>>> with an empty body ( empty array in JSON  ) if the collection or query
>>> result is empty.
>>>
>>> IMO the key is 200 status denote the sent result is valid and you use
>>> the empty body to convey the collection / query result is empty.
>>>
>>> For resources like /devices/{Id} will return 404 if the resource is not
>>> found.
>>>
>>> Regards
>>> Jo
>>>
>>>
>>> On Wed, Jun 15, 2016 at 12:26 PM, Chathura Dilan 
>>> wrote:
>>>
 ​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 
 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 
> 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 
>> 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 
>>> wrote:
>>>


 On Wed, Jun 15, 2016 at 10:11 AM, Ayyoob Hamza 
 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 

Re: [Dev] [EMM] Why we are using 404 for "No Content" responses ?

[Manuranga Perera]

204 is used if the file exist but it is an empty file. But in this case no
such type exists at all.


On Tue, Jul 12, 2016 at 10:11 AM, Madhawa Gunasekara 
wrote:

> Hi All,
>
> Why can't we simply use 204 as status code for the No Content responses?
> because according to the spec all the 2xx status codes are successful.
> AFAIU We should use 204 for No Content responses.
>
> Thanks,
> Madhawa
>
> On Wed, Jun 15, 2016 at 7:40 PM, Manuranga Perera  wrote:
>
>> Seems like the bigger issue here is that resource collection is not being
>>  a path parameter.
>>
>> /devices/type=android -> not ideal, there is no good way to distinguish
>> non-existing types
>> /devices/android -> seems to be more REST like
>>
>> On Wed, Jun 15, 2016 at 5:17 AM, Joseph Fonseka  wrote:
>>
>>> Hi All
>>>
>>> In AM what we practice is that collection resource will return 200 Ok
>>> with an empty body ( empty array in JSON  ) if the collection or query
>>> result is empty.
>>>
>>> IMO the key is 200 status denote the sent result is valid and you use
>>> the empty body to convey the collection / query result is empty.
>>>
>>> For resources like /devices/{Id} will return 404 if the resource is not
>>> found.
>>>
>>> Regards
>>> Jo
>>>
>>>
>>> On Wed, Jun 15, 2016 at 12:26 PM, Chathura Dilan 
>>> wrote:
>>>
 ​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 
 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 
> 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 
>> 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 
>>> wrote:
>>>


 On Wed, Jun 15, 2016 at 10:11 AM, Ayyoob Hamza 
 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

Re: [Dev] [EMM] Why we are using 404 for "No Content" responses ?

[Madhawa Gunasekara]

Hi All,

Why can't we simply use 204 as status code for the No Content responses?
because according to the spec all the 2xx status codes are successful.
AFAIU We should use 204 for No Content responses.

Thanks,
Madhawa

On Wed, Jun 15, 2016 at 7:40 PM, Manuranga Perera  wrote:

> Seems like the bigger issue here is that resource collection is not being
>  a path parameter.
>
> /devices/type=android -> not ideal, there is no good way to distinguish
> non-existing types
> /devices/android -> seems to be more REST like
>
> On Wed, Jun 15, 2016 at 5:17 AM, Joseph Fonseka  wrote:
>
>> Hi All
>>
>> In AM what we practice is that collection resource will return 200 Ok
>> with an empty body ( empty array in JSON  ) if the collection or query
>> result is empty.
>>
>> IMO the key is 200 status denote the sent result is valid and you use the
>> empty body to convey the collection / query result is empty.
>>
>> For resources like /devices/{Id} will return 404 if the resource is not
>> found.
>>
>> Regards
>> Jo
>>
>>
>> On Wed, Jun 15, 2016 at 12:26 PM, Chathura Dilan 
>> wrote:
>>
>>> ​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 
>>> 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 
 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 
> 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 
>> wrote:
>>
>>>
>>>
>>> On Wed, Jun 15, 2016 at 10:11 AM, Ayyoob Hamza 
>>> 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 

Re: [Dev] [EMM] Why we are using 404 for "No Content" responses ?

[Manuranga Perera]

Seems like the bigger issue here is that resource collection is not being
 a path parameter.

/devices/type=android -> not ideal, there is no good way to distinguish
non-existing types
/devices/android -> seems to be more REST like

On Wed, Jun 15, 2016 at 5:17 AM, Joseph Fonseka  wrote:

> Hi All
>
> In AM what we practice is that collection resource will return 200 Ok with
> an empty body ( empty array in JSON  ) if the collection or query result is
> empty.
>
> IMO the key is 200 status denote the sent result is valid and you use the
> empty body to convey the collection / query result is empty.
>
> For resources like /devices/{Id} will return 404 if the resource is not
> found.
>
> Regards
> Jo
>
>
> On Wed, Jun 15, 2016 at 12:26 PM, Chathura Dilan 
> wrote:
>
>> ​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  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 
>>> 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 
 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 
> wrote:
>
>>
>>
>> On Wed, Jun 15, 2016 at 10:11 AM, Ayyoob Hamza 
>> 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.
>>
>> 

Re: [Dev] [EMM] Why we are using 404 for "No Content" responses ?

[Geeth Munasinghe]

On Wed, Jun 15, 2016 at 10:11 AM, Ayyoob Hamza  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  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 
>> 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 
>>> 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 

Re: [Dev] [EMM] Why we are using 404 for "No Content" responses ?

[Joseph Fonseka]

Hi All

In AM what we practice is that collection resource will return 200 Ok with
an empty body ( empty array in JSON  ) if the collection or query result is
empty.

IMO the key is 200 status denote the sent result is valid and you use the
empty body to convey the collection / query result is empty.

For resources like /devices/{Id} will return 404 if the resource is not
found.

Regards
Jo


On Wed, Jun 15, 2016 at 12:26 PM, Chathura Dilan  wrote:

> ​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  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  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 
>>> 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 
 wrote:

>
>
> On Wed, Jun 15, 2016 at 10:11 AM, Ayyoob Hamza 
> 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 

Re: [Dev] [EMM] Why we are using 404 for "No Content" responses ?

[Chathura Dilan]

​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  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  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  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 
>>> wrote:
>>>


 On Wed, Jun 15, 2016 at 10:11 AM, Ayyoob Hamza  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 
> 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 

Re: [Dev] [EMM] Why we are using 404 for "No Content" responses ?

[Ruwan Yatawara]

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  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  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 
>> wrote:
>>
>>>
>>>
>>> On Wed, Jun 15, 2016 at 10:11 AM, Ayyoob Hamza  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 
 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
> 

Re: [Dev] [EMM] Why we are using 404 for "No Content" responses ?

[Ruwan Yatawara]

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  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  wrote:
>
>>
>>
>> On Wed, Jun 15, 2016 at 10:11 AM, Ayyoob Hamza  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  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 

Re: [Dev] [EMM] Why we are using 404 for "No Content" responses ?

[Rasika Perera]

>
> 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 
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  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 
>> wrote:
>>
>>> +1
>>>
>>> Harshan Liyanage
>>> Senior Software Engineer
>>> Mobile: *+94724423048*
>>> Email: hars...@wso2.com
>>> Blog : http://harshanliyanage.blogspot.com/
>>> *WSO2, Inc. :** wso2.com *
>>> lean.enterprise.middleware.
>>>
>>> On Tue, Jun 14, 2016 at 1:42 PM, Geeth Munasinghe 
>>> 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  *
 *lean.enterprise.middleware.*

 email: ge...@wso2.com
 phone:(+94) 777911226

 On Tue, Jun 14, 2016 at 11:48 PM, Harshan Liyanage 
 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

Re: [Dev] [EMM] Why we are using 404 for "No Content" responses ?

[Geeth Munasinghe]

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  *
*lean.enterprise.middleware.*

email: ge...@wso2.com
phone:(+94) 777911226

On Tue, Jun 14, 2016 at 11:48 PM, Harshan Liyanage  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 *
> lean.enterprise.middleware.
>
> On Tue, Jun 14, 2016 at 12:42 PM, Geeth Munasinghe  wrote:
>
>> Hi Ayyoob
>>
>> On Tue, Jun 14, 2016 at 11:01 PM, Ayyoob Hamza  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
>>
>>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [EMM] Why we are using 404 for "No Content" responses ?

[Kamidu Punchihewa]

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  wrote:

> +1
>
> Harshan Liyanage
> Senior Software Engineer
> Mobile: *+94724423048*
> Email: hars...@wso2.com
> Blog : http://harshanliyanage.blogspot.com/
> *WSO2, Inc. :** wso2.com *
> lean.enterprise.middleware.
>
> On Tue, Jun 14, 2016 at 1:42 PM, Geeth Munasinghe  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  *
>> *lean.enterprise.middleware.*
>>
>> email: ge...@wso2.com
>> phone:(+94) 777911226
>>
>> On Tue, Jun 14, 2016 at 11:48 PM, Harshan Liyanage 
>> 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 *
>>> lean.enterprise.middleware.
>>>
>>> On Tue, Jun 14, 2016 at 12:42 PM, Geeth Munasinghe 
>>> wrote:
>>>
 Hi Ayyoob

 On Tue, Jun 14, 2016 at 11:01 PM, Ayyoob Hamza  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


>>>
>>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev