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

Bharat,

Think I got most your idea described above.

Question: Do you want to have a generic way to expand rest resources?

We could do that by analyzing the fields parameter 
(fields=tag_item.tag,tag.title,tag.count 
<http://x.com/g3/rest/item_tags/1?output=html&fields=tag_item.tag,tag.title,tag.count>).
But this is tricky!
Much easier would be that a rest resource (e.g. item_tags) checks all 
field parameters and in case it knows how to handle them does the 
needful (e.g. calls another rest resource, puts some specific fields 
into the json payload etc.).


The second seems to be much easier, but results in dependencies between 
the rest resources.

*
*

On 5/16/11 6:43 AM, Bharat Mediratta wrote:
>
>
> On Sun, May 15, 2011 at 3:07 PM, David Steinberger 
> <[email protected] <mailto:[email protected]>> wrote:
>
>
>     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?
>
>
> I was thinking that instead of separating out the related fields, we'd 
> expand them inline.
>
> *WHAT WE HAVE NOW:*
>
> REQUEST: GET /rest/item/1?output=html
> RESPONSE: array(
>   'url' => 'http://x.com/g3/rest/item/1?output=html',
>   'entity' => array(
>     'id' => '1',
>     ...
>   ),
>   'relationships' => array(
>     'comments' => ...
>     'tags' => array(
>       'url' => 'http://x.com/g3/rest/item_tags/1?output=html',
>       'members' => array(
>       ),
>     ),
>   ),
>   'members' => array(
>     0 => 'http://x.com/g3/rest/item/2?output=html',
>   ),
> )
>
> ==========
>
> *WHAT WE'D HAVE WITH FIELDS:*
>
> REQUEST: GET 
> /rest/item/1?output=html&fields=tag_item.tag,tag.title,tag.count
> RESPONSE: array(
>   'url' => 
> 'http://x.com/g3/rest/item/1?output=html&fields=tag_item.tag,tag.title,tag.count 
> <http://x.com/g3/rest/item/1?output=html&fields=tag_item.tag,tag.title,tag.count>',
>   'entity' => array(
>     'id' => '1',
>     ...
>   ),
>   'relationships' => array(
>     'comments' => ...
>     'tags' => array(
>       'url' => 
> 'http://x.com/g3/rest/item_tags/1?output=html&fields=tag_item.tag,tag.title,tag.count 
> <http://x.com/g3/rest/item_tags/1?output=html&fields=tag_item.tag,tag.title,tag.count>',
>       'members' => array(
>         0 => array(
>           'url' => 
> 'http://x.com/g3/rest/tag_item/1,1?output=html&fields=tag_item.tag,tag.title,tag.count 
> <http://x.com/g3/rest/tag_item/1,1?output=html&fields=tag_item.tag,tag.title,tag.count>',
>           'entity' => array(
>    'tag' => array(
>               'url' => 
> 'http://x.com/g3/rest/tag/1?output=html&fields=tag_item.tag,tag.title,tag.count 
> <http://x.com/g3/rest/tag/1?output=html&fields=tag_item.tag,tag.title,tag.count>',
>      'entity' => array(
>                 'title' => 'ThisIsMyTag',
>                 'count' => '2'
>               )
>             )
>           ),
>         ),
>       ),
>     ),
>   ),
>   'members' => array(
>     0 => 'http://x.com/g3/rest/item/2?output=html',
>   ),
>
>
> Some things to note here:
> 1) Even though the format of the response changes, it's consistent 
> because it's dictated by the query parameters.
>
> 2) We expand the tag_item resource because there's an "tag_item.tag" 
> field specified.  We still present the url as before in the expanded 
> data structure, but we *only* expand the tag element underneath it (so 
> the item field normally in the entity is dropped).
>
> 3) We then expand the tag resource below the item_tags resource 
> because we requested the tag.title and tag.count fields.  The id field 
> is ignored.
>
> GOTCHAS:
>
> One problem here is that the tag resource contains a relationship back 
> to tag_item, so we'd then expand *that* tag_item which would in turn 
> expand its tag, and we'll have an infinite loop.  I haven't figured 
> out whether that's an implementation detail or if we need something in 
> the design to prevent it from happening.
>
>
>
>     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 ]
>
>

------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including 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 ]