Ticket #1240 (new enhancement) — at Version 3
[super] API v4
Reported by: | rgrp | Owned by: | |
---|---|---|---|
Priority: | awaiting triage | Milestone: | ckan-backlog |
Component: | ckan | Keywords: | |
Cc: | Repository: | ckan | |
Theme: | none |
Description (last modified by rgrp) (diff)
(Just creating this ticket as somewhere to keep notes)
- Tidying
- Unify on /api/v{version num}/... structure (do we want a default option that points to current default? e.g. /api/default/ ...)
- extras merged into normal field list in package
- Get rid of /rest/ so just have api/v1/package
- Get rid of separation of search api from 'rest' api
- Propose that GET on REST index is search e.g. /package/?q=...
- This is also resolves issue whereby GET at root returns whole package set (a *bad* idea) as this would now become the matchall search query (with a default limit on items returned)
- Propose that GET on REST index is search e.g. /package/?q=...
- Resource read/write in API (separate from package)
- Does this need authorization work?
- user/account API - read/write
- Remove autocomplete -- can just use search
- Do not worry about backwards compat as should only be used in our js (if others using it too bad!)
Change History
comment:1 Changed 3 years ago by rgrp
- Summary changed from [super] API v3 to [super] API v4
- Milestone changed from ckan-v1.5 to ckan-backlog
comment:2 Changed 3 years ago by dread
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?
Note: See
TracTickets for help on using
tickets.