带有 URL 参数的 HTTP POST - 服务器应该回复什么？
我正在设计一个 RESTFul 服务，它为各种域对象提供 CRUD 操作。 Person 就是这样的对象之一。
我们提供以下服务：
GET /person/list?type=Infant
响应所有婴儿类型的人。
POST /person/list
接受有效负载中的人员列表并创建这些记录。
问题： 这是否有意义
POST /person/list?type=Infant
在这种情况下，我们将创建在有效负载中传递的人员，然后以婴儿类型的所有人员的列表进行响应，
？最佳做法是什么？
I'm working on designing a RESTFul service which provides CRUD operations for various domain objects. One such object is Person.
We have the following services:
GET /person/list?type=Infant
responds with all persons of the type Infant.
POST /person/list
accepts a list of persons in the payload and creates those records.
Question:
Does it make sense for
POST /person/list?type=Infant
in which case, we would create the persons passed in the payload and then respond with a list of all persons of the type Infant?
What's the best practice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我对这种说法不满意：“创建在有效负载中传递的人员，然后以婴儿类型的所有人员的列表进行响应”。这两个操作应该分开进行。
I am not comfortable with this statement: "create the persons passed in the payload and then respond with a list of all persons of the type Infant". The two operations should be performed separately.
我认为 /person/list 作为添加人员的 api 没有多大意义。如果有的话应该是/person/add。 REST 没有任何具体内容禁止您尝试变得聪明，但我期望对 /person/add 的响应将是添加的结果。尝试嫁接一些额外的功能只会让您的客户（即将使用您的 API 的人）变得更加复杂。
I don't think that it makes much sense for /person/list to be the api for adding a person. If anything it should be /person/add. There's nothing specific about REST that forbids you from trying to be clever, but the response I would expect on a /person/add would be the result of the add. Trying to graft on some extra functionality just makes it more complicated for your clients (ie. the people who will be using your API).