REST api 服务上下文和资源 url

Question

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

http://url:port/Draws

但是，现在讨论的是此服务的 api 路径（资源）。由于我们得到平局，在我看来这应该是平局。这意味着它将具有 url

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

2 次抽奖 - 想法？

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

然后是实现，我们使用的是Jersey。这意味着我们将拥有 @Path("{gameNo}").

的资源

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

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

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

的版本部分

Answer 1

不要让书籍、图书馆或章节弄乱你的思想。只看您的实体："Draws" 是您的实体吗？那么它应该是 http://url:port/draws/{gameNo}

休息API设计，您可以阅读以下资源：

我建议你看看理查森成熟度模型。

我也喜欢Github API。（以前他们建议我们读代码来提高我们的才能，现在你也可以读休息 APIs。）

Answer 2

如果你设计一个 Draws 服务，你 url 应该是：

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

如果您计划使用其他端点扩展服务，您可能正在设计更通用的东西。如果是这种情况，请相应地命名。

无论如何你都不应该选择 draws/draws。

此外，我建议使用小写字母和 https（如果可以的话）。

最近我发布了设计时最常出现的问题的总结 RESTful API - How To Design Practical RESTful API ，这可能会有所帮助。

Answer 3

我会避免使用 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 与服务器提供的其他资源（例如 webapp ).它通常采用 /api 的形式。对于仅服务于 REST apis 的服务器，可以省略。
api name 将一组资源集合在一种包中。这是发布和版本控制的单位。
api版本是API的版本。它的形式为 v[major-version-number]
resource path由资源URI段组成

REST api service context and resources url