微服务中 REST 的 URL 模式答案

【问题标题】：URL patterns for REST in Microservices微服务中 REST 的 URL 模式
【发布时间】：2018-12-04 04:43:24
【问题描述】：

我们正在考虑（主要是）RESTful 微服务的最佳 URL 方案。每个服务都有自己的上下文。主题标签（如 Instagram）特定逻辑的服务会执行与主题标签相关的所有操作。一个用户服务，完成所有注册用户的处理等等。

所以我们认为每个 URL 都以 /api 开头，然后是每个服务的上下文。在这种情况下，例如 /api/hashtag 或 /api/user

问题在于这些服务与“核心”资源同名。例如，用户服务有一个列出所有用户的资源，因此 URL 必须类似于 /api/user/user。主题标签也是如此。该服务中有一个资源列出了所有主题标签。所以 URL 必须是 /api/hashtag/hashtag。

现在您遇到了问题：“核心”资源听起来与服务完全一样。我们正在为此寻找一个好的解决方案。有没有这方面的最佳做法？

谢谢！

【问题讨论】：

为什么网址必须有这些模式？我真的没看到。

标签： rest url design-patterns microservices

【解决方案1】：

最好将服务命名为 /api/serviceName/resource 话虽如此，您的问题是服务名称。我们以前做的一件事是在名称中添加服务。说 UserService 或 OrderService。我还看到名称为 oms（代表订单管理服务）ims 等。您可以有 order-management/order 或 user-management/user。

如果它是一个内部 api，您还可以继续为您的服务使用一些代号。

或者你可以放弃服务名称。您的路由逻辑可能会膨胀，但对于外部客户，他们真的不在乎他们在与谁交谈。你可以保留 /api/order 或 /api/user

【讨论】：

被否决，因为：个人意见（未引用相关来源），而 OP 明确要求最佳实践；缺少复数（见接受的答案）；没有解释为什么“内部 API”的 URL 可能/应该不同（我不同意，因为没有充分的理由会更难理解）

【解决方案2】：

网址命名背后的基本原理是Resource Oriented Architecture (ROA)。即资源层次结构。

让我们从您的问题中举一个例子。你有一个用户服务。我假设您将user 视为root resource。

所以让我们定义一个用户的样子。举个例子吧。

User

     | - code

     | - name

     | - cars

这里我假设一个用户可以有一个代码、名称和一些汽车（可以不止一辆）。

现在让我们看看如何看到汽车。

Car

     | - number

     | - make

     | - model

     | - year

现在您可以为这样的用户定义一个 json 对象。

{
    "code": "001A",
    "name": "alice",
    "cars": [
        {
            "number": "ab123",
            "make": "toyota",
            "model": "corolla",
            "year": 2015
        },
        {
            "number": "we345",
            "make": "nissan",
            "model": "sunny",
            "year": 2017
        }
    ]
}

因此，如果我想提供一个端点来检索所有用户，我会提供一个这样的端点。

/api/user-service/users

请注意 users（-- 复数），因为我可以拥有多个用户。它会产生这样的响应..

[
    {
        "code": "001A",
        "name": "alice",
        "cars": [
            {
                "make": "toyota",
                "model": "corolla",
                "year": 2015
            },
            {
                "make": "nissan",
                "model": "sunny",
                "year": 2017
            }
        ]
    },
    {
        "code": "001B",
        "name": "bob",
        "cars": [
            {
                "make": "toyota",
                "model": "yaris",
                "year": 2016
            },
            {
                "make": "bmw",
                "model": "318i",
                "year": 2017
            }
        ]
    }
]

如果我们需要一个端点来检索特定用户的数据，我会给出这样的端点。

/api/user-service/users/{user-code}

例子

/api/user-service/users/001A

所以它会产生这样的响应。

{
    "code": "001A",
    "name": "alice",
    "cars": [
        {
            "number": "ab123",
            "make": "toyota",
            "model": "corolla",
            "year": 2015
        },
        {
            "number": "we345",
            "make": "nissan",
            "model": "sunny",
            "year": 2017
        }
    ]
}

如果我们想要一个端点来检索给定用户的所有汽车，它会是这样的。

/api/user-service/users/{user-code}/cars

请注意，汽车（--复数）

例子

/api/user-service/users/001A/cars

所以它会产生这样的响应。

[
    {
        "number": "ab123",
        "make": "toyota",
        "model": "corolla",
        "year": 2015
    },
    {
        "number": "we345",
        "make": "nissan",
        "model": "sunny",
        "year": 2017
    }
]

希望您对 REST url 命名约定有基本的了解。

【讨论】：