在 REST 中处理添加/删除多对多关系的正确方法是什么？

发布于 2024-10-09 07:41:53 字数 251 浏览 0 评论 0原文

假设我们有一个实体，其中包含服务器上的用户列表，并且我们希望将其公开为其余实体。正确的做法是什么？

我的第一个猜测是这样的：

/entity/1/user/5

我们可以使用 PUT 进行更新，使用 DELETE 进行删除吗？

这是对的吗？我去了维基百科，那里谈到了休息，他们的观点是一切都只有一层深。那么也许他们希望您使用 PUT/POST 并提供整个 JSON 图表并立即更新整个内容？

原文

Let's say we have an entity that contains a list of users on the server, and we want to expose this as rest. What is the proper way to do it?

My first guess is something like this:

/entity/1/user/5

We can use PUT for updates and DELETE for deletes?

Is this right? I went to wikipedia where it talks about rest, and their view of it is that everything is only 1 level deep. So maybe they want you to use PUT/POST and give the entire JSON graph and update the entire thing all at once?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

我是男神闪亮亮 2024-10-16 07:41:53

你的例子是一个完全有效的方法。
然而，在许多情况下，用户可以存在于实体的上下文之外。我倾向于单独识别资源，例如：

/entity/1
/user/5

要查看与实体关联的用户，我将使用：

/entity/1/users

添加用户可以通过 POST 用户来完成，

POST /entity/1/users
<User>
...
</User>

删除用户可以

DELETE /User/5

通过 PUT 来完成，

PUT /User/6

删除关联用户和实体之间需要一点创造力。您可以

DELETE /Entity/1/User/5

按照您的建议进行操作，或者类似的操作

DELETE /Entity/1/UserLink?UserId=5

，或者只是

DELETE /Entity/1/Users?UserId=5

您的 URI 的外观对于您的 API 用户来说，现实并不是很重要。为了您自己的理智保持一致是件好事，选择易于与您的服务器框架分派的方案也很好，但重要的不是您的 URI 的外观，而是您如何使用它们。

Your example is a perfectly valid approach.
However in many cases a User can exist outside of the context of just entity. I tend to identify resources in isolation, e.g:

/entity/1
/user/5

To see users associated to an entity I would use:

/entity/1/users

Adding a user could be done by POSTing a user,

POST /entity/1/users
<User>
...
</User>

Deleting a user would be

DELETE /User/5

Updating or creating a user could be done with PUT

PUT /User/6

Removing the association between a user and an entity requires a bit of creativity. You could do

DELETE /Entity/1/User/5

as you suggested, or something like

DELETE /Entity/1/UserLink?UserId=5

or just

DELETE /Entity/1/Users?UserId=5

It reality is not very important to the user of your API what your URI looks like. It's good to be consistent for your own sanity, it is good to choose schemes that are easy to dispatch with your server framework, but it is not what your URIs look like, it is what you do with them that is important.

回复收藏 0 原文

虐人心 2024-10-16 07:41:53

我将您的方法用于父/子实体，但对于多对多，我在 JSON 对象中使用一个数组来表示该实体。

因此，使用您的示例：

GET /entity/1

将返回一个类似这样的实体对象：

{"entityID":1,"name":"whatever","users":[1,2,3,4,5]}

PUT 将传入同一个对象，并更新实体和用户。然后获取特定的用户信息：

GET /users/3

对 users/3 使用 PUT 将更新用户。 PUT on /entity/1 会将用户连接到实体。不幸的是，关于如何建模此类事物的好信息并不多。

I use your method for parent/child entities, but for many-to-many I use an array in my JSON object representing that entity.

So using your example:

GET /entity/1

would return an entity object something like this:

{"entityID":1,"name":"whatever","users":[1,2,3,4,5]}

PUT would pass in this same object, and update both the entity and the users. Then to get the specific user info:

GET /users/3

Using PUT on users/3 would update the user. PUT on /entity/1 would connect users to entities. Unfortunately, there's not not a lot of good info out there on how to model this sort of thing.

回复收藏 0 原文

~没有更多了~