On 02/22/2013 01:31 PM, Nick Coghlan wrote:
You *could* just use the bare URLs instead of moving them inside a
namespace like that, but it gives you a lot more freedom to create
self-describing data if you don't.
To make this a little less abstract...
These would be the results for application/json.
application/xml would only be supported for individual recipes, and
would give the standard Beaker recipe XML
GET /recipes/
- list of all recipes in the recipeset
- each entry includes the *full* representation that would be
returned by a GET for that recipe
GET /recipes/1234/
- returns a JSON mapping, for example:
{
"_type" : "recipe",
"url": "http://lab.controller.fqdn/api/recipes/1234/",
"tasks": {
"_type": "link",
"rel": "collection/tasks",
"url":
"http://lab.controller.fqdn/api/recipes/1234/tasks/"
},
"logs": {
"_type": "link",
"rel": "collection/logs",
"url":
"http://lab.controller.fqdn/api/recipes/1234/logs/"
},
"remote-logs": {
"_type": "link",
"rel": "collection/remote-logs",
"url":
"http://lab.controller.fqdn/api/recipes/1234/remote-logs/"
},
"watchdog": 8760
}
GET /recipes/1234/tasks/
- list of all tasks in the recipe
- each entry includes the *full* representation that would be
returned by a GET for that task
GET /recipes/1234/tasks/678/
- returns a JSON mapping, for example:
{
"_type" : "task",
"url":
"http://lab.controller.fqdn/api/recipes/1234/tasks/678/",
"recipe": {
"_type": "link",
"rel": "resource/recipe",
"url": "http://lab.controller.fqdn/api/recipes/1234/"
},
"results": {
"_type": "link",
"rel": "collection/results",
"url":
"http://lab.controller.fqdn/api/recipes/1234/tasks/678/results/"
},
"logs": {
"_type": "link",
"rel": "collection/logs",
"url":
"http://lab.controller.fqdn/api/recipes/1234/tasks/678/logs/"
},
"remote-logs": {
"_type": "link",
"rel": "collection/remote-logs",
"url":
"http://lab.controller.fqdn/api/recipes/1234/tasks/678/remote-logs/"
}
}
If you insist on using a stateful non-self-describing design instead,
then I *will* ask you to use a "/v1/" prefix as Bill suggested.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Python Applications Team Lead
Beaker Development Lead (
http://beaker-project.org/)
PulpDist Development Lead (
http://pulpdist.readthedocs.org)