朋友名单的休息惯例
我有一个数据库（ORM），其用户看起来像这样：
UserEntity (
id: UUID,
name: String,
phoneNumber: String,
friends: List<UserEntity>
)
我也有以下朋友终点：
GET /user/<userId>/friends (returns a list of UUID's for all friends the user has)
POST /user/<userId>/friends?friendId=<friendId> (saves a new friend to the friends list)
DELETE /user/<userId>/friends?friendId=<friendId> (deletes a friend from the friends list)
现在我问自己：这是实现安息的朋友列表的正确方法吗？朋友。是否应该从以下路径达到朋友资源：
GET /user/<userId>/friends/<friendId>
或从以上路径上：
GET /user/<friendId>
从上方的两个给定端点回馈相同的资源（一个配置文件），但我应该选择哪一个？我正在深入研究休息惯例，但我没有找到任何明确的答案。我什至不知道我目前的休息设计是否正确。事先感谢您的帮助。
I have a database (ORM) with users which look like this:
UserEntity (
id: UUID,
name: String,
phoneNumber: String,
friends: List<UserEntity>
)
I also have the following friends endpoints:
GET /user/<userId>/friends (returns a list of UUID's for all friends the user has)
POST /user/<userId>/friends?friendId=<friendId> (saves a new friend to the friends list)
DELETE /user/<userId>/friends?friendId=<friendId> (deletes a friend from the friends list)
Now I asked myself: is this the correct way of implementing a RESTful friend list and what is a good REST convention to obtain the profile of a friend. Should the friend resource be reached from the following path:
GET /user/<userId>/friends/<friendId>
Or from this path:
GET /user/<friendId>
Both of the given endpoints from above give back the same resource (a profile) but which one should I choose? I am diving deeper into REST conventions but I didn't find any clear answer for this. I dont't even know if my current REST design is correct. Thanks in advance for your help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您在说什么，我将称为NICE URL惯例。 https://en.wikipedia.org/wiki/wiki/clean_url 与休息无关 https：// https：//www.ics.ics.uci.uci.uci.uci.uci.uci.uci.uci.uci.uci.uci.uci.ucfielding/~fielding/~fielding/~fielding/~fielding/~fielding/ pubs/dissertation/fielding_dissertation.pdf 我不知道为什么人们认为它有。从剩余的角度来看，做
get | put | delete /dsgvs23w？x235rwef = 1＆amp; aegs234523f = 2 < /code>并根据描述它描述它的元数据遵循哪个URL，将同样好。 。如果您违反Hateoas，那么您就没有REST API。在“不错的URL惯例”之后关于友谊，例如
强度= bff，持续时间= 20y等。但是，有无限的解决方案，这实际上取决于您的需求。What you are talking about I would call nice URL convention. https://en.wikipedia.org/wiki/Clean_URL It has nothing to do with REST https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf and I have no idea why people think it has. From the REST point of view it would be equally good to do something like
GET|PUT|DELETE /dsgvs23w?x235rwef=1&aegs234523f=2and decide which URL to follow based on the metadata that describes it. If you violate HATEOAS, then you don't have a REST API.As of the nice URL convention I would do something like
GET /friendships/?user=1andGET|PUT|DELETE /friendships/1+2and add some extra info about the friendship e.g.strength=BFF, duration=20y, etc. But there are infinite good solutions for this and it really depends on your needs.