jxstanford
|
Posted: September 28, 2009 15:32 by jxstanford
|
|
This may apply to other operations, but I was looking at Create VM, and had a couple questions: 1) Just curious. The example URI format in the Create VM documentation on the wiki (http://kenai.com/projects/suncloudapis/pages/CloudAPIClusterRequests) differs from what I've seen in other examples. In the case below, I would have expected to see "POST /clusters/123456" and the resulting VM URI something like /clusters/123456/vms/web02. Doesn't the format used below sort of defeat the navigability of RESTful resources or am I missing something? REQUEST POST /clusters/cluster=123456 Host: example.com Authorization: Basic xxxxxxxxxxxxxxxxxxx Accept: application/vnd.com.sun.cloud.VM+json Content-Length: nnn Content-Type: application/vnd.com.sun.cloud.VM+json X-Cloud-Client-Specification-Version: 0.1 { "name" : "web02" "from_template": "http://example.com/templates/xyz", "data_disk" : 100 } RESPONSE HTTP/1.1 202 Accepted Content-Type: application/vnd.com.sun.cloud.Status+json Content-Length: nnn { "op": "new-VM", "progress": 100, "target_uri": "/vms?cluster=123456&vm=web02", "status_uri": "/statuses?op=new-VM&cluster=123456&name=web02", "status": 201 } 2) The example returns a status of 201 in the status field though the request returns a status of 202. I get it, but what happens if I call the status_uri? Is it possible to get a 200? If so, the "Response Status: 202, 400, 401, 403, 404" needs to be updated. 3) Is there value in having an "In Progress" status or something to make the response consistent regardless of the state of the operations? |
Doc questions Create VM
29 topics, 131 posts
» Share this
Replies: 2 - Last Post: September 30, 2009 23:30
by: jxstanford
by: jxstanford
showing 1 - 3 of 3
Tim Bray
|
Posted: September 28, 2009 23:23 by Tim Bray
|
|
1) Pardon me being dense, but I don't understand the question. I'm not seeing the connection between the shape of the URL and navigability. Please try again? 2) Nope, the POST can only return 202/400/etc. If you do a GET on the status_uri, I would expect that you would normally get a 200, but that's not the operation that's being described here. 3) Do you mean a string value fo the "progress" field? Give us an example or two of what you have in mind? |
|
jxstanford
|
Posted: September 30, 2009 23:30 by jxstanford
|
|
It's probably me being dense... 1) Disregard, you are right. One just seems more intuitive to me over the other. Chalk it up to personal preference. 2) ok 3) I really meant another int status so the response format would be the same. Currently a response with an incomplete request is something like: { "op": "new-VM", "progress": 0, "target_uri": "/vms?cluster=123456&vm=web01", "status_uri": "/statuses?op=new-VM&cluster=123456&name=web01", } While a completed response is something like : { "op": "new-VM", "progress": 100, "target_uri": "/vms?cluster=123456&vm=web02", "status_uri": "/statuses?op=new-VM&cluster=123456&name=web02", "status": 201 } One has a status field and the other doesn't, though in the real world they both have a status. So I'm suggesting that there may be room for a "status":205 or some other number that makes sense for things that have been submitted, but are not completed. It might make sense to have: 205 = Submitted (equivalent to progress = 0) 206 = In Progress (equivalent to 0 < progress < 100) |
Replies: 2 - Last Post: September 30, 2009 23:30
by: jxstanford
by: jxstanford
