Question

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

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

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

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

谢谢！

Answer 1

URL命名的基础是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

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

[
    {
        "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网址命名约定有基本的了解。

Answer 2

将服务命名为/ api / serviceName / resource是一个好习惯话虽如此，您的问题是服务名称。我们曾经做的一件事是将Service添加到名称中。说出UserService或OrderService。我也看到过名字是oms（代表订单管理服务）ims等。您可以拥有订单管理/订单或用户管理/用户。

如果它是内部api，您还可以为服务添加一些代码名称。

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

微服务中REST的URL模式

2 个答案: