REST 端点 - 最佳实践

Question

我有以下 REST 端点，但不确定它是否遵循最佳实践。不同的网站说不同的事情。所以想在这里验证一下。

GET - /api/v1/service/prj             --> To get projects for the logged in user

GET - /api/v1/service/prj/upcoming    --> To get upcoming projects for the logged in user

GET - /api/v1/service/prj/upcoming/all --> To get all projects for admin user

GET - /api/v1/service/prj/{prj_id}   --> To get all projects for admin user

GET - /api/v1/service/prj/usr/{user_id}

GET - /api/v1/service/prj/usr/all

GET - /api/v1/service/prj/usr/{user_id}/upcoming

GET - /api/v1/service/prj/usr/{user_id}/open

GET - /api/v1/service/prj/details/{prj_id}

这里，问题是，

获取 - /api/v1/service/prj/upcoming

获取 - /api/v1/service/prj/{prj_id}

在 Spring 路由器中，如果我先放置第二个，/prj/{prj_id} 将匹配 /prj/upcoming。所以试图了解最佳实践。

我在想其他路线，例如，

代替 /prj/comping 使用 prj-upcoming。请帮我看看这里的最佳实践。

此外，路径参数和查询参数使用下划线。

喜欢，{prj_id}。但是，我看到一些使用 prjId 的链接。使用路径和查询参数的最佳实践是什么？

Answer 1

REST 不关心您对资源标识符使用什么拼写约定，只要这些约定与 RFC 3986 中定义的生产规则一致即可。

特别是：从 REST 组件的角度来看，标识符在语义上是不透明的，您可以使用任何标识符来引用您喜欢的任何文档。

GET - /api/v1/service/prj/upcoming
GET - /api/v1/service/prj/{prj_id}

这是一个路由问题；客户不关心，但正如您发现的那样，您的路由实现确实关心。

你能做什么？

您可以更改拼写约定 - 很好
您可以更改路由实施 - 很好
您可以编写自己的逻辑来解决歧义 - 很好

在任何健全的系统中，您不能做的事情是允许一个标识符引用两个不同的资源。

因此，只要在您的内部架构中明确“即将到来”永远不是有效的 prj_id（无论是因为prj_id 始终是数字或始终是 UUID，或者因为保留字不允许作为 prj_id 并且“即将到来”是保留字......随便你喜欢什么）。

REST 端点 - 最佳实践

REST end points - Best practice

rest

api-design