英文:
How to request REST API correctly for GET & DELETE without resources ID?
问题
请告诉我是否我误解了。
获取所有活跃用户
GET /api/users?active
如果我想获取所有活跃用户的消息怎么办
GET /api/users/active/messages
或者如果我想删除所有非活跃用户的消息怎么办
DELETE /api/users/no-active/messages
英文:
Please let me know if I misunderstanding.
Getting all active users
> GET /api/users?active
What if I want to get all active user's messages
> GET /api/users/active/messages
Or what if I want to delete all active user's messages
> DELETE /api/users/no-active/messages
答案1
得分: 1
不同的方法可以具有相同的路由：
删除（DELETE）仍然可以相同：
DELETE /api/users/active/messages
英文:
Different methods can have same route:
Delete (DELETE) can still be the same:
DELETE /api/users/active/messages
答案2
得分: 1
关于如何正确请求REST API以进行GET和DELETE操作而不需要资源ID的问题，从REST的角度来看，这个问题并不太合理。任何具名信息都可以是一个资源，我们使用资源标识符（也称为URI）来识别我们要谈论的资源。
在这个查询中，/api/users?active是一个资源标识符（RFC 7230中称为请求目标的原始表达方式）。
在这种情况下，您的资源是“所有活跃用户”，或者更准确地说是“所有活跃用户的列表”；这个列表的表示将根据当前活跃的用户而变化。
同样的理念在这里也适用，资源是消息列表。
通常情况下，当我们尝试修改一个资源时，我们使用资源的标识符作为更改的目标URI。因此，对消息列表的修改都将共享一个通用的目标URI：
POST /api/users/active/messages
PUT /api/users/active/messages
PATCH /api/users/active/messages
DELETE /api/users/active/messages
这是因为URI作为缓存键，熟悉HTTP缓存语义的通用组件会知道使之无效之前缓存的资源表示。
在HTTP中，DELETE具有精确的语义含义，即删除标识符与其表示之间的关联。成功的DELETE的自然结果是，随后的GET将返回404 Not Found（表示请求的目标URI没有当前的表示）。
如果您的意图是修改表示，那么POST/PUT/PATCH是更自然的选择。
PUT /api/users/active/messages
Content-Type: application/json
[]
这个消息的含义是“用这个新的表示替换你当前的表示”。
当您的实现只是一个文档存储时，将一个表示替换为另一个表示非常简单 - 您验证传入的表示，然后用新的表示覆盖旧的表示。对于动态生成的表示，支持相同的语义要复杂得多。
如果您想要删除所有消息，将一个“删除所有消息”的请求POST到资源可能会更容易，而不是尝试PUT一个新的表示。
英文:
> How to request REST API correctly for GET & DELETE without resources ID?
From the perspective of REST, this question doesn't make a lot of sense. Any named information can be a resource, and we use the resource identifier (aka, the URI) to identify which resource we are talking about.
GET /api/users?active
In this query, /api/users?active is a resource identifier (what RFC 7230 refers to as the request-target expressed in origin form).
Your resource, in this case is "all active users", or perhaps more precisely "the list of all active users"; the representation of that list will change over time depending on which users are currently active.
GET /api/users/active/messages
Same idea here, the resource is the list of messages.
Now normally when we are trying to modify a resource, we use the identifier of the resource as the target-uri for the change. So modifications to the list of messages would all share a common target-uri
POST /api/users/active/messages
PUT /api/users/active/messages
PATCH /api/users/active/messages
DELETE /api/users/active/messages
This is because the URI serves as a cache key, and general-purpose components that are familiar with HTTP caching semantics will know to invalidate any previously cached representations of the resource.
In HTTP, DELETE has a precise semantic meaning, which is to remove the association between the identifier and its representations. The natural consequence of a successful DELETE is that a subsequent GET would return a 404 Not Found (which means that the requested target-uri has no current representation).
If what you are intending is to modify the representation, then POST/PUT/PATCH are the more natural choices.
PUT /api/users/active/messages
Content-Type: application/json
[]
is a message that means "replace your current representation with this one".
Replacing one representation with another is pretty trivial when your implementation is just a document store - you validate the incoming representation, and then overwrite the old representation with the new. With dynamically generated representations, supporting the same semantics is a lot more work.
It may ease your life considerably to POST a "delete all messages" request to the resource, rather than trying to PUT a new representation.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论