GRAILS-10683

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

GRAILS-10683

Jeff Scott Brown-2
Does this seem like the correct thing to do?…

https://github.com/grails/grails-core/commit/d46b87f9f4e1c673ad3fc5c8f628ca892ef69ab6



JSB

--
Jeff Scott Brown  
[hidden email]  

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: GRAILS-10683

beckje01
At the company I work at, we have taken the view that an empty collection is content such as when doing a search and getting an empty result that is still content to our consumers. 

We use a 204 only when there is nothing to return such as with a successful PUT, I know that seems borderline I have seen much more around only using a 204 in response to DELETE only. 

Jeff


On Mon, Dec 16, 2013 at 4:16 PM, Jeff Scott Brown <[hidden email]> wrote:
Does this seem like the correct thing to do?…

https://github.com/grails/grails-core/commit/d46b87f9f4e1c673ad3fc5c8f628ca892ef69ab6



JSB

--
Jeff Scott Brown
[hidden email]

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: GRAILS-10683

bobbywarner
I also think that it should be returned as 200 with an empty collection as opposed to 204.  

Also, with HATEOS APIs, you will always have links in the response even if the collection is empty.  So, there will always be some content (200) as opposed to no-content (204).


Hope that helps!
Bobby


On Mon, Dec 16, 2013 at 4:53 PM, Jeff Beck <[hidden email]> wrote:
At the company I work at, we have taken the view that an empty collection is content such as when doing a search and getting an empty result that is still content to our consumers. 

We use a 204 only when there is nothing to return such as with a successful PUT, I know that seems borderline I have seen much more around only using a 204 in response to DELETE only. 

Jeff


On Mon, Dec 16, 2013 at 4:16 PM, Jeff Scott Brown <[hidden email]> wrote:
Does this seem like the correct thing to do?…

https://github.com/grails/grails-core/commit/d46b87f9f4e1c673ad3fc5c8f628ca892ef69ab6



JSB

--
Jeff Scott Brown
[hidden email]

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email




Reply | Threaded
Open this post in threaded view
|

Re: GRAILS-10683

pledbrook
In reply to this post by Jeff Scott Brown-2
> Does this seem like the correct thing to do?…
>
> https://github.com/grails/grails-core/commit/d46b87f9f4e1c673ad3fc5c8f628ca892ef69ab6

From the HTTP spec:

    The 204 response MUST NOT include a message-body

and

    If the client is a user agent, it SHOULD NOT change its document
view from that which caused the request to be sent.

The HTML list view will have a response body. The JSON one should
really be returning '[]'. And I would expect in most cases that the
client should change its view based on an action that uses respond().

In other words, I'm with Jeff and Bobby on this one.

Peter

--
Peter Ledbrook
t: @pledbrook

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: GRAILS-10683

Graeme Rocher-2
In retrospect, yeah 204 doesn't seem appropriate.


On Thu, Dec 19, 2013 at 8:27 AM, Peter Ledbrook <[hidden email]> wrote:
From the HTTP spec:

    The 204 response MUST NOT include a message-body

and

    If the client is a user agent, it SHOULD NOT change its document
view from that which caused the request to be sent.

The HTML list view will have a response body. The JSON one should
really be returning '[]'. And I would expect in most cases that the
client should change its view based on an action that uses respond().

In other words, I'm with Jeff and Bobby on this one.

Peter

--
Peter Ledbrook
t: @pledbrook

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email





--
Graeme Rocher
Grails Project Lead
SpringSource
Reply | Threaded
Open this post in threaded view
|

Re: GRAILS-10683

Jeff Scott Brown-2


On December 19, 2013 at 4:50:47 AM, Graeme Rocher ([hidden email]) wrote:
>  
> In retrospect, yeah 204 doesn't seem appropriate.
>  
>  
>

Agreed.

A challenge the system has as it is currently written is that the respond method isn't able to figure out how to represent an empty collection in the response.  Renderers are associated with a type and a mime-type(s).  The respond method inspects the first element in the collection to determine what type is being rendered.  When the collection is empty, there isn't any context which the respond method can interrogate to figure out what type is being rendered so it can't select a renderer.  Right now when that situation arises the respond method responds with 415.

One thing we could do is require that a type be passed as an argument to the respond method but requiring that would be disruptive to existing code.  Another option is to overload the respond method to optionally accept the type in which case if the type is specified, that type (along with the mime type of course) is used to locate the appropriate renderer.  If the type is not specified, the system could behave as it does today.

Another option is when an empty collection is rendered we can just look for any collection renderer that knows about the relevant mime type and if one exists, use it.  In practice this is probably going to be fine because often there will only be 1 and when there are multiple the differences may only be in the part of the content which won't be relevant for an empty collection.

I think I prefer overloading the respond method and changing the default scaffolding and resource stuff to take advantage of that, allowing all of the existing application code to continue to behave as it currently does.

Input is appreciated.  What say ye?

Thanks.



JSB


Jeff Scott Brown
[hidden email]

Autism Strikes 1 in 166  
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: GRAILS-10683

Graeme Rocher-2
I would go for a mixed approach. Allow being explicit (via type argument) and if not specified just use the renderer for java.lang.Object

Cheers


On Fri, Dec 20, 2013 at 10:36 AM, Jeff Scott Brown <[hidden email]> wrote:


On December 19, 2013 at 4:50:47 AM, Graeme Rocher ([hidden email]) wrote:
>
> In retrospect, yeah 204 doesn't seem appropriate.
>
>
>

Agreed.

A challenge the system has as it is currently written is that the respond method isn't able to figure out how to represent an empty collection in the response.  Renderers are associated with a type and a mime-type(s).  The respond method inspects the first element in the collection to determine what type is being rendered.  When the collection is empty, there isn't any context which the respond method can interrogate to figure out what type is being rendered so it can't select a renderer.  Right now when that situation arises the respond method responds with 415.

One thing we could do is require that a type be passed as an argument to the respond method but requiring that would be disruptive to existing code.  Another option is to overload the respond method to optionally accept the type in which case if the type is specified, that type (along with the mime type of course) is used to locate the appropriate renderer.  If the type is not specified, the system could behave as it does today.

Another option is when an empty collection is rendered we can just look for any collection renderer that knows about the relevant mime type and if one exists, use it.  In practice this is probably going to be fine because often there will only be 1 and when there are multiple the differences may only be in the part of the content which won't be relevant for an empty collection.

I think I prefer overloading the respond method and changing the default scaffolding and resource stuff to take advantage of that, allowing all of the existing application code to continue to behave as it currently does.

Input is appreciated.  What say ye?

Thanks.



JSB


Jeff Scott Brown
[hidden email]

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email





--
Graeme Rocher
Grails Project Lead
SpringSource