Ticket #1174 (closed enhancement: wontfix)

Opened 3 years ago

Last modified 3 years ago

API Representation Registry

Reported by: pudo Owned by: pudo
Priority: major Milestone: pdeu-1
Component: lod2 Keywords:
Cc: [email protected] Repository: ckan
Theme: dictization


As CKAN grows, more and more optional representations of packages will become used. Besides RDF (which is the motivation for this ticket), support for DSPL, home-grown XML, or CSV listings is imaginable.

To properly support this CKAN should have an extensible representation registry that can be extended when new output types become available (and without changing the API in the process). This needs to integrate in two places:

  • We need to add support for file format extensions to the package handler and REST API.
  • We need to add HTTP content type negotiation (Accept headers).

To support this we should have a registry with two registers:

  • to map format extensions to mime types (e.g. "json" -> "application/json")
  • to map mime types and entity types to converter functions (e.g. 8"application/json", ckan.model.Package) -> func(obj, mime_type) )

This should be set up on load_environment so that IConfigurer plugins can feed into it.

The registry should then first be added to _finish in the REST API (which needs to be refactored to be passed the {format} part of the URL if one is given. Based on the format part and HTTP headers, an appropriate representation can be generated by the registry and then be returned to the user.

Forwarding of requests to the regular WUI controllers with Accept headers set or a format specified can be implemented in a separate effort.

Change History

comment:1 Changed 3 years ago by amercader

comment:2 Changed 3 years ago by pudo

  • Status changed from new to closed
  • Resolution set to wontfix

wontfix as thejimmyg wants to turn REST API into RPC API and this doesn't fit in.

Not an excellent plan in my idea but this is to be discussed elsewhere.

Note: See TracTickets for help on using tickets.