如果我传递以下 URI /apps/{id}?control=start 是否是 REST
我正在为我们的网络应用程序设计 REST API。
发布> /应用程序>创建应用程序
放置> /apps/{id} >更新应用程序
我想要启动应用程序。 这是 REST 吗?如果不是,我怎样才能让它更加 RESTful?
- 发布> /apps/{id}?control=start
Sun Cloud API 执行以下操作: http://kenai.com /projects/suncloudapis/pages/CloudAPISpecificationResourceModels
或者更好的是:
2. PUT /apps/{id} 并在响应 Json/XML 中包含状态参数?
3. POST /apps/{id} 并在响应 Json/xml 中包含状态参数?
4. POST /apps/start?app={id}
I'm in the process of designing a REST API for our web app.
POST > /apps > Creates an app
PUT > /apps/{id} > Updates the app
I want to start the apps.
Is this REST and if not, how can I make it more RESTful?
- POST > /apps/{id}?control=start
Sun Cloud API does this: http://kenai.com/projects/suncloudapis/pages/CloudAPISpecificationResourceModels
Or is it better to:
2. PUT /apps/{id} and include a status parameter in the response Json/XML?
3. POST /apps/{id} and include a status parameter in the response Json/xml?
4. POST /apps/start?app={id}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
我认为这里正确的问题更多的是 HTTP 动词是否按预期使用,而不是应用程序是否尽可能 RESTful。然而,如今这两个概念几乎相同。
PUT
的特点是,无论您PUT
是什么,您都应该能够立即GET
。换句话说,PUT
对资源进行了批量替换。如果存储在apps/5
中的资源具有“control”属性作为其状态的一部分,那么 control=start 部分应该是您放置的表示的一部分。如果您只想发送新的资源片段,那么您正在执行 PATCH,而不是 PUT。PATCH 并未得到广泛支持,因此恕我直言,您应该使用 POST。 POST没有安全性或幂等性要求;一般来说,您可以使用 POST(或多或少)做任何您想做的事情,包括修补资源的某些部分。毕竟,这就是您使用 POST 在集合中创建新项目时所做的事情。更新资源的一部分并没有太大的不同。
一般来说,尽管您在请求正文中发布新数据,而不是作为查询参数。查询参数主要用于 GET,因为您正在查询。 :)
I think the right question here is more whether the HTTP verbs are being used as intended rather than whether the application is or is not as RESTful as possible. However, these days the two concepts are pretty much the same.
The thing about
PUT
is that whatever youPUT
you should be able to immediatelyGET
. In other words,PUT
does a wholesale replacement of the resource. If the resource stored atapps/5
is something that has a "control" attribute as part of its state, then the control=start part should be part of the representation you put. If you want to send just the new piece of the resource, you are doing a PATCH, not a PUT.PATCH is not widely supported, so IMHO you should use a POST. POST has no requirements of safety or idempotency; generally you can do whatever you want with a POST (more or less), including patching parts of a resource. After all that is what you do when you create a new item in a collection with a POST. Updating a portion of a resource is not really much different.
Generally though you POST new data in the request body, not as query parameters. Query parameters are used mostly for GETs, because you are, well, querying. :)
启动应用程序会改变它的状态吗? (例如“正在运行”)如果它执行的操作是更新资源(应用程序)的状态。这似乎是 PUT 操作的一个很好的用途。尽管正如 Ray 所说,如果控制是资源状态的一部分,则
PUT
请求的正文应包含您正在更新的状态。我相信可以进行部分更新(CouchDB 使用此)。另一方面,如果启动应用程序意味着创建新资源(例如,代表应用程序执行),则
POST
方法将非常适合。您可能会得到这样的结果:这将导致
HTTP/1.1 201 Created
。然后,要访问有关创建的执行的信息,您可以使用如下 URL:对我来说,这似乎是一个很好的“Restful”方法。如需了解更多信息,请查看这篇文章。
Does starting an app changes it state? (to "running", for example) If it does what you're actually doing is updating the state of the resource (application). That seems like a good use for the
PUT
operation. Although as Ray said, if control is part of the state of the resource, the body of thePUT
request should contain the state you're updating. I believe a partial update would be possible (CouchDB uses this).On the other hand, if starting an app means creating a new resource (representing the app execution, for example), the
POST
method would be a great fit. You could have something like this:Which would result in a
HTTP/1.1 201 Created
. Then, to access the information on the created execution, you could use a URL like this:To me, this would seem like a good "Restful" approach. For more information, check out this article.
PUT apps/{id}
我会 PUT 应用程序以将其状态从
off
更新为on
PUT apps/{id}
I would PUT the app to update it's status from
off
toon
我喜欢做类似的事情
I like to do something like,