[ckan-dev] API Representation Registry

Fri Jun 3 10:56:39 UTC 2011

On 3 June 2011 10:51, Friedrich Lindenberg
<friedrich.lindenberg at okfn.org> wrote:
> Hi David,
>
> On Fri, Jun 3, 2011 at 11:38 AM, David Read <david.read at okfn.org> wrote:
>> I'm pretty lost on the meaning this ticket. Are you talking about a
>> mapping between the way we store metadata in our model and a way we
>> can send/receive it over the API and or Web UI?
>
> I'm in turn not sure what you mean by that but I think yes: its about
> mapping expected mime types to methods for the creations of object
> representations in these types. Example:
>
> The request
>   GET /api/rest/package/foo HTTP/1.1 \n Accept: application/json \n
> Host: ckan.net
> would look up g.representation_registry[('application/json', Package)]
> be returned a function like: to_json(obj, mime_type)
> and then return the output generated by this.
>

Ah, that is very helpful - I understand what's going on now. A few questions.

Why do you describe the representation registry as extensible?

Why do you need to store the representation extensions?

We expect the harvester to import packages in these sorts of
representations too. It would be good to check that round-tripping of
each of these transformations works. What do you think?

The autoneg we use in the WUI seems relevant here - why not use that here?

David

>> Also, what's this alternative routing hack you mentioned?
>
> https://bitbucket.org/okfn/ckanext-pdeu/src/d35bfe5e16f5/ckanext/pdeu/controllers.py
>
> ... In which we would get to implement lookup, error handling and
> authorization a third time. (In the current implementation breaking
> support for groups etc. btw)
>
> - Friedrich
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>