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

On Wed, May 18, 2011 at 10:59 AM, David Steinberger <[email protected]>wrote:

>
> 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.
>

I was thinking the second approach as well.  The rest framework could parse
the fields param into $request->fields and each get() function checks that
and does the right thing.  I don't see that causing any dependencies between
rest resources -- can you explain what you're worried about there?


On 5/16/11 6:43 AM, Bharat Mediratta wrote:
>
>
>
> On Sun, May 15, 2011 at 3:07 PM, David Steinberger <[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
> ',
>   '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
> ',
>       'members' => array(
>         0 => array(
>           'url' => '
> 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
> ',
>       '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]
>> > 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/<<item
>>> id>>?output=html
>>> Response:
>>> array (
>>>     'url' => '
>>> http://localhost/~david/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 ]