[ckan-dev] Tags REST API update

[Adrià Mercader]

Sounds very reasonable.
Let's leave like this then.

Cheers,

Adrià

2011/7/21 David Read <david.read at okfn.org>:
> 2011/7/21 Adrià Mercader <amercadero at gmail.com>:
>> Hi all,
>> Working on the refactoring of the controllers, I found a small
>> incongruence in the tags REST API.
>>
>> In the groups case, if you query:
>> http://test.ckan.net/api/2/rest/group
>> you get a list of all group ids, and querying
>> http://test.ckan.net/api/2/rest/group/0ac963e7-ba29-49bc-83c8-98f8c1991649
>> gives you the details of the group, including the packages contained
>>
>> Similarly,
>> http://test.ckan.net/api/2/rest/tag
>> gives you a list of all the tag names (not ids! Is this intentional?).
>
> Yes this was intentional. A tag object is seen to be an immutable
> string. This makes the id we store internally irrelevant.
>
>> But querying a specific tag:
>> http://test.ckan.net/api/2/rest/tag/country-uk
>> only returns the list of ids of packages that have that tag.
>
> Yes this is correct.
>
>> Is anyone against that on the new version of the API /rest/tag/<id>
>> returns a JSON object with the details of the tag (including of course
>> the packages)?
>
> I can see that it would make the internal logic more consistent, and
> maybe a client that treats all our objects the same, having an ID and
> other properties. But the fact remains that a tag is simply an
> immutable string, with no other properties about from its links to
> Packages, so how it is now is the simplest and most understandable
> thing. So I think it's a balance of simplicity vs consistency and
> either is arguable.
>
> Dave
>
>>
>>
>> Adrià
>>
>> _______________________________________________
>> ckan-dev mailing list
>> ckan-dev at lists.okfn.org
>> http://lists.okfn.org/mailman/listinfo/ckan-dev
>>
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>