Ticket
remove wagn from canonical URLs+solution
Outlined here:
Mapping REST to Decko is quite simple, because Decko only has one type of resource: the cards. The API maps standard REST actions to standard card actions in a straightforward way.
How To
Basic API
GET / # index. if given name as CGI variable, acts just like GET /name
GET /name # read if exists, "new" form if not GET /name?view=edit # read in specified view if exists, "new" form if not. GET /?view=new # new card form POST / POST /name # create new card PUT / PUT /name # update card DELETE / DELETE /name # delete card (move to trash)
Variants
Names
Cards can be identified in three ways:
- name - default
- codename - begins with ":"
- id - begins with "~"
Names can be given in CGI params or in path. Error if 2 different names are given. Note that if a nonexistent codename or id is given in a normal GET request, response is 404 (not "new")
Formats
You can add ".<format extension>" to the end of any requests to specify the response file formats.
CGI Variables
Including:
- view args - eg layout, view, item, size, keyword
- action args - (not sure what those are yet)
- model args for PUTS and POSTS - eg name, type, content
Currently those model args come as card[name], card[type], etc. We need to decide if that is still valuable (for example, in separating them from view/action args and how to specify nested cards, which will probably be some variant on that pseudo-hash structure.
GET Variants
POST /name -> GET /create/name PUT /name -> GET /update/name
DELETE /name -> GET /delete/name
# and, for consistency...
GET /name -> GET /read/name
Tips
Discussion
I guess there are two remaining questions:
1. do we infer new card view from ?type=X
2. should the new view of a type card be the new view of an instance of that type.
At the moment, both seem a bit hacky to me, and indeed would require minor code hacks, because they don't fit our current patterns. In general we use new view when (a) explicitly told to, or (b) going to a card with a name we don't recognize. Seems clean to keep it that way. #2 seems to introduce a class/instance confusion we don't have elsewhere.
I don't feel super strongly about this and I may have leaned a different way before, but now that the code is cleaner, I'm more resistant to hacks than ever.
moving to 1.9. Most of the heavy loading has been done, but I don't think we're quite ready to change the canonical behavior yet.
actually, the part explicitly named in this ticket (removing /wagn in canonical urls) is done, but the we should add another ticket for support RESTful Web API (for 1.9).
--Ethan McCutchen.....Thu Dec 22 13:23:55 -0800 2011