CKAN: Ticket #1240: [super] API v4

summary, milestone changed

rgrp — Mon, 01 Aug 2011 10:06:21 GMT

summary changed from [super] API v3 to [super] API v4
milestone changed from ckan-v1.5 to ckan-backlog

dread — Wed, 24 Aug 2011 10:08:08 GMT

I basically agree, but just thought I'd add a couple of comments into the mix.

GET at root returns whole package set (a *bad* idea)

Sure it has a cost, but I don't see what the problem with this is if the list is cached. Forcing developers to paging through the list of packages is putting unnecessary obligations. I'd say that the top two RESTful operations are listing objects and getting a particular one, and you'd be taking away one of those.

Unify on /api/v{version num}/... structure

Where is it not currently unified?

description changed

rgrp — Wed, 14 Sep 2011 17:42:25 GMT

description modified (diff)

add autocomplete

status, milestone changed; owner set

rgrp — Mon, 19 Dec 2011 18:25:19 GMT

owner set to kindly
status changed from new to assigned
milestone changed from ckan-backlog to ckan-v1.6

assigning to kindly for review

description changed

rgrp — Mon, 19 Dec 2011 18:26:29 GMT

description modified (diff)

dread — Mon, 19 Dec 2011 18:41:47 GMT

Although I'm generally in favour of Action API over RESTful, Action API does need some sorting out wrt listing methods, advertising what params are allowed and checking those that are passed. Using the Action API is so hard without reading the code!

The RESTful API is handy when you want to do something quickly in a browser. I'd not want to lose these two, for example:

to look at a package /api/rest/dataset/xyz
API version etc. at /api/util/status (coming with ckan 1.5.2)

It's also really handy in demos and to send as links to people on the list.

milestone changed

rgrp — Mon, 02 Jan 2012 03:01:52 GMT

milestone changed from ckan-v1.6 to ckan-backlog

IMO this is non-urgent and can move out of v1.6 as we have enough more important stuff to do.