Re: Follow up on: Tags rest resource request for mobile apps

So if I get this right, your proposed way is the following:

We go with a fields parameter:

    * The syntax of this one is <<data_model>>.<<field_name>>.
      data_model: is any related data record;
      field_name: is any 'column' from this related record
    * The rest-resource can return either a single value or an array of
      values

Something like this:
GET /rest/item/1?fields=<<table>>.<<column-name>> ==>
'url' => '',
'entity' => array(),
'relationships' => array(),
'related_fields' =>
array (
     'url' => '<<url identifier>>',
     'member' => '<<row-value>>'
),
'members' => array()

or

GET /rest/item/1?fields=tags.tag_name ==>
'url' => '',
'entity' => array(),
'relationships' => array(),
'related_fields' =>
array (
     'url' => '<<url identifier>>',
     'members' =>
     array (
         0 => 'value1',
         1 => 'value2',
         2 => 'value3',
         3 => 'value4',
     ),
),
'members' => array()

IMHO we'd need this fields-logic on the items and the tree-resource.
The implementation could be similar to the existing 'relationships' 
logic, isn't it?

On 5/15/11 9:07 PM, Bharat Mediratta wrote:
>
>
> On Thu, May 12, 2011 at 11:48 AM, David Steinberger 
> <[email protected] <mailto:[email protected]>> wrote:
>
>     I created a very simple tag_values module that delivers all tag
>     values for a given item id.
>     Based on the tags modules ... very simple. Cool!
>
>     It's like this:
>     Request:
>     http://localhost/~david/gallery3/index.php/rest/tag_values/
>     <http://localhost/%7Edavid/gallery3/index.php/rest/tag_values/><<item
>     id>>?output=html
>     Response:
>     array (
>         'url' =>
>     'http://localhost/~david/gallery3/index.php/rest/tag_values/
>     <http://localhost/%7Edavid/gallery3/index.php/rest/tag_values/><<item
>     id>>?output=html',
>         'members' =>
>         array (
>             0 => 'tag1',
>             1 => 'tag2',
>             2 => 'tag3',
>             3 => 'tag4',
>         ),
>     )
>
>
>     Question on consistency:
>     I implemented relationships($resource_type, $resource). Now it
>     shows up in the item-rest-resource under relationships. Just
>     great. BUT: It's not consistent!
>     Usually rest-resources should only put restful urls in
>     'relationships', isn't it?
>
>     How should this be structured? Via a parameter on the rest-resources?
>     I was thinking about '&resolveRelationships=true/false, what do
>     other think?
>
>
> So if I understand it correctly, what you really want here is to 
> display information about the tag itself so that you don't have to 
> make a second query?    I think what you want is the "fields" 
> parameter that we've been discussing on this thread:
>
> http://old.nabble.com/REST-docs-td27351326.html
>
> Essentially, some resources would just be a URL, some would be a data 
> structure containing the url with *some* fields inlined.  I think the 
> code is relatively easy to write, but nobody's done it yet.  If you 
> want to take a shot at it this week, we could still get it into 3.0.2.
>
>
>
>     1 Gallery3 question:
>     Why does $request->url result in an item id (context
>     rest::resolve($request->url))?
>     Where's this defined/coded? Just want to understand what I'm
>     actually doing :).
>
>
> I'm not sure I exactly follow what you mean.  rest::resolve looks at 
> the url (eg: "tag_values/3") and breaks it up into two parts 
> ("tag_values", "3") then calls tag_values_rest::resolve("3") which 
> returns something arbitrary.
>
> The important thing is that your rest resource's resolve() and url() 
> functions match up, so for example:
>
>   tag_values_rest::url("3") == "tag_values/3"
>   tag_values_rest::resolve("tag_values/3") == "3"
>
> Does that make sense?
>
>
>     Thx,
>       David
>
>     Btw. gallery3 & kohana are fantastic to work with.
>     And sorry to start a new conversion, but can't follow up on the
>     old one.
>
>
> thanks!
>
>
>     ------------------------------------------------------------------------------
>     Achieve unprecedented app performance and reliability
>     What every C/C++ and Fortran developer should know.
>     Learn how Intel has extended the reach of its next-generation tools
>     to help boost performance applications - inlcuding clusters.
>     http://p.sf.net/sfu/intel-dev2devmay
>     __[ g a l l e r y - d e v e l ]_________________________
>
>     [ list info/archive --> http://gallery.sf.net/lists.php ]
>     [ gallery info/FAQ/download --> http://gallery.sf.net ]
>
>
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
>
>
> __[ g a l l e r y - d e v e l ]_________________________
>
> [ list info/archive -->  http://gallery.sf.net/lists.php ]
> [ gallery info/FAQ/download -->  http://gallery.sf.net ]

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay

__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]