java - REST api 服务上下文和资源 url

Question

我们在应用程序服务器上运行多项服务，并且每个服务都有一个上下文。服务名称会自动添加到 url 中，因为同一应用程序服务器上可以有多个服务。
现在我们正在创建一个新服务，称为 Draws，这意味着 url 将是

http://url:port/Draws

但是，现在讨论的是该服务的 api 路径(资源)。既然我们是平局，在我看来这应该是平局。 这意味着它将有 url

http://url:port/Draws/draws/{gameNo}

2 次抽奖 - 想法？

这里有人认为该服务只有抽奖，因此 Draws/{gameNo} 就足够了。
但在我看来，draws 资源就是服务的 api 接口(interface)，就像 Draws 是图书馆里的书，draws 是章节......而且应该可以在书中添加更多章节。

然后为了实现，我们使用 Jersey。这意味着我们将拥有一个带有 @Path("{gameNo}") 的资源。

编辑1:
我们的服务前面有网关，因此上下文永远不会暴露给最终用户，它只是指向特定的服务。由于多个服务可以在同一主机上运行:端口

编辑2:
url 的上下文部分是服务发现查找的一部分

编辑3:
我们实际上不是在 url 中进行版本控制，而是在 Accept header 中进行版本控制，所以实际上我的 url 与 clementinos 相同，但 url 的版本部分

Answer 1

我会避免使用 2x 'draws'。

这是设计 URI 结构的一种可能方法。 请注意，段应该小写(因此不要使用“Draws”)

<scheme>://<host>[:<port>]/<api-path>/<api-name>/<api-version>/<resource-path>

• 方案(例如http)
• host 是完全限定的主机名，是隐藏 API 实现的设备和物理位置的 DNS 别名。当它是非生产环境时，它包含有关环境的信息(test、int)。
• port 应该是默认的 http 端口 (80)，因此可以省略。其他端口可用于非生产环境。
• api path 将 REST API 与服务器提供的其他资源(例如 Web 应用程序)分开。它通常采用/api 形式。对于仅提供 REST api 的服务器，可以省略。
• api name 在一种包中收集一组资源。这是发布和版本控制的单位。
• api 版本是 API 的版本。它的格式为 v[主版本号]
• 资源 路径由资源 URI 段组成