Returning something other than nil from a find_all call with no results?

[gbright@vuzit]

Hello all,

We currently have a web service api that returns a list of matches
from a find_all call.

result = []
result= Event.find_all(params)

respond_to do |format|
format.xml { render :xml => result.to_xml(:skip_types => true) }
format.json { render :json => result.to_json(:skip_types => true) }
end

When no relevant matches are found, the xml that is returned is "<nil-
classes/>"

We'd like a way to return a root node with the same name as the
object, but with nothing inside it, so instead the user would get
"<events />" We'd also like some way to do it so that both the xml
and json would return the root "events" node, but without having to
write separate code paths for the two formats so the respond_to block
stays clean. Of course, we could always check if the call returned no
results, and if so, pass in an xml or json string with what we want,
but we're wondering if there is a cleaner and easier way to do it to
avoid several if-else blocks.

Thanks.

[Angel Pizarro]

I would stick with "

if @result

  ... 

else 

 head( :not_found ) and return

end 
-angel

--
Angel

[Erik Hollensbe]

foo = Event.find_all(params) || []

I'm not sure if an empty array is what you want, but you can replace
that right side with whatever you want.

[Chris Conley]

You could then pass in the 'root' option to #to_xml:

format.xml  { render :xml  => result.to_xml(:skip_types => true, :root => controller_name) }

[Angel Pizarro]

To clarify, I think sending back the standard "Not Found" HTTP code (404) fits better in my world view of a uniform interface of REST, in effect requiring the client to handle HTTP exceptions in a standard way. 

As Chris mentions later, a XML or JSON root of the controller or model class is a good choice, if you want the client to instead handle the "empty set" case. 

But this provides no feedback to the client as to whether the request was valid in the first place, or if there really are no resources that can be returned from a valid query. I guess it depends on your requirements.  

-angel

--
Angel

[Angel Pizarro]

and to complete my thought, you could send back status 401 for unauthorized requests, 400 bad request format, 403 forbidden ... 

-angel 

--
Angel

[Jim Guistwite]

Using the http status codes is a good idea. A quick search shows both
Digg and Twitter APIs
returning 404s under various conditions.

I'm not sure if one would use 404 for a list response or only for
individual items.
If I am asking for a particular item and it doesn't exist, I think 404
seems right. If I'm asking for a list
of items and none exist, perhaps an empty list is more appropriate.
The list exists but
there are no items contained in it.

[Angel Pizarro]

Good point. In that case I would do as Chris suggested and provide the
root with an empty set

Angel Pizarro

[gbright@vuzit]

We do have error checking on the request and return the status codes
if there's something wrong with the request. As was said, this was
more for a case where a user passes in a correct request that should
return a list, but there are no matches. In any case, Chris's
solution was exactly what we needed. Thanks a lot!

On Oct 24, 8:32 am, Angel Pizarro <delag...@gmail.com> wrote:
> Good point. In that case I would do as Chris suggested and provide the  
> root with an empty set
>
> Angel Pizarro
>

> On Oct 23, 2009, at 6:54 PM, Jim Guistwite <jguistw...@gmail.com> wrote:
>
>
>
> > Using the http status codes is a good idea.  A quick search shows both
> > Digg and Twitter APIs
> > returning 404s under various conditions.
>
> > I'm not sure if one would use 404 for a list response or only for
> > individual items.
> > If I am asking for a particular item and it doesn't exist, I think 404
> > seems right.  If I'm asking for a list
> > of items and none exist, perhaps an empty list is more appropriate.
> > The list exists but
> > there are no items contained in it.
>

> > On Fri, Oct 23, 2009 at 2:19 PM, Angel Pizarro <delag...@gmail.com>  

> > wrote:
> >> and to complete my thought, you could send back status 401 for  
> >> unauthorized
> >> requests, 400 bad request format, 403 forbidden ...
> >> -angel
>

> >> On Fri, Oct 23, 2009 at 2:17 PM, Angel Pizarro <delag...@gmail.com>  

> >>>> On Fri, Oct 23, 2009 at 12:04 PM, gbright@vuzit <theblackoi...@yahoo.com