带有URL参数的HTTP POST - 服务器应回应什么？

我正在设计一个为各种域对象提供CRUD操作的RESTFul服务。一个这样的对象是Person。带有URL参数的HTTP POST - 服务器应回应什么？

我们有以下服务：

GET /person/list?type=Infant

与婴儿型的所有人员作出响应。

POST /person/list

接受有效载荷中的人员列表并创建这些记录。

问：是否有意义的

POST /person/list?type=Infant

在这种情况下，我们将创建一个有效载荷传递的人，然后用型婴儿的所有人员的名单作出回应？

最佳做法是什么？

来源

2011-08-26 Sam

我对此陈述并不舒服：“创建通过有效载荷的人员，然后用所有类型的婴儿的人员列表作出回应”。这两个操作应该分开进行。

来源

2011-08-26 03:49:27

谢谢，谨慎讲解？我正在尝试阅读HTTP规范以及Atom Pub。我找不到任何明确禁止的地方。如果我遵循这种方法，可能遇到什么问题？ – Sam

您可能不会遇到任何问题，但通常客户端会启动服务器处理并返回适当响应的请求。在'POST/persons'的情况下，应该创建一个新的条目（人员）。在这种情况下，资源名称不会在clinet的请求中指定，新的对象URL路径将返回给您。新条目的ID由服务器创建，通常作为对此POST操作的响应返回。 POST会创建一个子资源，所以发布到/ persons创建一个资源位于/ persons资源下，例如/ persons/sam –

我认为/人/列表不适合添加人。如果有的话应该是/人/添加。没有任何关于REST的具体说明，它禁止你尝试变得聪明，但是我期望的/ person/add的响应将是add的结果。尝试移植一些额外的功能只会让你的客户（即将使用你的API的人）变得更加复杂。

来源

2011-08-26 03:55:22 gview

发布到/ person/list以添加新个人没有任何问题。这是非常普遍的惯例。 –

我没有说它有什么问题。但是，我认为这种方法没有任何价值，REST当然没有指定使用约定。例如，已经存在很长一段时间的Flickr使用它来上传照片：http：//api.flickr.com/services/upload/。只是因为你可以做点什么并不意味着你应该这样做。 – gview

使用具有动词的URI的问题在于，它并不总是显而易见的是请求的语义。例如，GET/person/add会做什么？ –

带有URL参数的HTTP POST - 服务器应回应什么？

回答

相关问题