我有一个用例,其中一些上下文需要从UI转移到后端,后端需要根据该上下文决定并发送响应。
这可以通过在请求正文中发送上下文并在服务器端通过解析请求正文来实现,可以在响应正文中发送表示形式。
我怀疑哪种HTTP方法适合于此?
GET:如果我们使用GET,则可以发送请求正文,但建议该正文不应具有与请求相关的任何语义。 看到这个:http-get-with-request-body
所以我只剩下POST或PUT,但是它们对应于更新或创建资源,使用它们可能会引起误解。
所以我的问题是,在这种情况下可以使用哪种适当的HTTP方法,这在RESTful设计观点中是可以接受的。
感谢您的答复。
我正在考虑使用POST或PUT,因为在服务器端使用请求主体没有任何限制。
编辑:
我认为POST将达到我的目的。 RFC HTTP RFC 7231表示POST可用于: 为数据处理过程提供数据块,例如以HTML表单形式输入的字段
所以对我来说,数据处理过程是后端服务器,HTML表单等效于任何UI元素。 因此,我可以使用POST方法将数据发送到后端,并将现有资源表示作为响应主体发送,http状态代码为200
答案 0 :(得分:1)
请记住,GET
仅可用于数据检索,且无副作用。也就是说,GET
既是安全也是幂等(请参阅更多详细信息here)。
如果该操作是幂等的,请执行PUT
:
PUT
方法请求创建目标资源的状态或将其替换为请求消息有效负载中包含的表示形式所定义的状态。给定表示的成功PUT
表示,同一目标资源上的后续GET
将导致在200
(确定)响应中发送等效的表示。 [...]
否则,选择POST
,它是捕获所有动词:
POST
方法请求目标资源根据资源自身的特定语义来处理请求中包含的表示形式。 [...]
答案 1 :(得分:0)
我会选择POST
,因为在REST中,PUT
用于创建像user这样的新资源。
答案 2 :(得分:0)
有一个PATCH
发布方法,用于更改内容,也许就是您要找的东西
答案 3 :(得分:0)
所以我的问题是,在这种情况下可以使用什么合适的HTTP方法,这在RESTful设计观点中是可以接受的。
万维网就像您将要找到的RESTful一样,HTML表单仅支持GET
(其中should not have a request body和POST
)。因此POST
一定可以(而且可以)。
更一般地说,POST
可以用于任何事物;当其他方法更适合语义时,应使用其他方法。例如,您可以使用POST
来使资源不可用,但是DELETE
更为明确,并且通用组件可以做有意义的事情,因为它们可以识别语义。当您打算为服务器提供资源的新表示形式时,PUT
比POST
是更好的选择。
我无法理解为什么禁止HTTP GET的有效负载
禁止HTTP GET的有效负载,因为标准说“不要那样做”。
我相信它是通过这种方式来简化用于缓存响应的规则的。如所写,缓存实现只需要担心头数据(包括起始行上的信息)。
但这可能很简单,因为该标准的较早版本不需要通用组件对GET请求的消息主体做任何特定的事情,因此现代规范说“不要那样做”以保持向后兼容性。 (设计寿命长的系统的重要限制之一是,您不能破坏较早的实现。)