我正在编写一个只做一件事的小应用程序:获取一些用户提供的数据,对其进行一些分析,并返回该数据的“标记”。我认为客户应该GET
或POST
向/getTag
提出请求,以便获得回复。
当客户端执行此操作时,服务器上不存储任何内容,因此使用POST会感觉很奇怪。但是,分析中也没有统一的URI,因此使用GET会感觉很奇怪,因为它会根据提供的数据返回不同的内容。
用REST表示此功能的最佳方式是什么?
答案 0 :(得分:2)
“最佳方式”是做最适合您的应用及其需求的方法。不知道,这里有一些想法:
GET
是最合适的动词,因为您不是在服务器上创建或存储任何内容,只是检索服务器提供的内容。
请勿按照建议将get
放在URI中。这样的动词已经由HTTP提供,因此只需使用/tag
和GET
代替。
您应该为此资源使用一个易于理解(或“酷”)的URI,并将数据作为查询参数传递。我不担心它感觉很奇怪(见this question's答案,找出原因)。
总结一下,只需GET
/tag?foo=bar&beef=dead
,就可以了。
答案 1 :(得分:1)
POST可以表示执行操作。该操作 不是数据库操作。
您真正创建的是远程过程。 RPC通常都是POST。我认为这不适合REST,但这并不妨碍您使用简单的URL和JSON。
答案 2 :(得分:1)
在我看来,您或者生成原始数据的用户可能希望生成的标记能够持久存在,不是吗?
如果有可能,那么我将其写为POST /tags
并将/tags/:id
资源URI作为Location:标头传回。
如果我真的不关心持久化生成的标签,我会考虑“用户生成的数据”是什么以及幕后发生了多少处理。如果“标记”与传递到系统的任何数据不同,GET /tag
可能会让API使用者感到困惑。
答案 3 :(得分:0)
我将回答Brian的回答:使用GET
。如果相同的输入参数返回相同的输出,并且您实际上并没有创建任何内容,则它是幂等操作,因此非常适合GET
。
答案 4 :(得分:0)
您可以使用GET
和POST
:
GET /tag?data="..." -> 200, tag
GET方法意味着检索任何信息(以。的形式) entity)由Request-URI标识。如果Request-URI引用 数据生成过程,它是生成的数据 作为响应中的实体而不是源文本返回 过程,除非该文本恰好是过程的输出。
POST /tag {data: "..."} -> 200, tag
POST方法执行的操作可能不会产生资源 可以通过URI识别。在这种情况下,200(OK)或204 (No Content)是适当的响应状态,具体取决于是否 或不响应包括描述结果的实体。
根据HTTP标准/ method definitions部分。
如果我是你,我会使用GET
(仅当你想发送文件时才使用POST
。)