Шаблоны URL для REST в микросервисах - PullRequest
0 голосов
/ 25 июня 2018

Мы думаем о лучшей схеме URL для наших (в основном) микросервисов RESTful.У каждого сервиса свой контекст.Служба для определенной логики хэштегов (например, Instagram) делает все, что связано с хэштегами.Пользовательский сервис, который выполняет всю обработку зарегистрированных пользователей и т. Д.

Поэтому мы подумали, что каждый URL начинаем с / api, а затем с контекста каждого сервиса.В этом случае, например, / api / hashtag oder / api / user

Проблема заключается в том, что эти службы имеют то же имя, что и ресурс "core".У службы пользователя есть ресурс, который, например, перечисляет всех пользователей, поэтому URL-адрес должен быть примерно таким: / api / user / user.То же самое касается хэштегов.В этой службе есть ресурс, в котором перечислены все хэштеги.Таким образом, URL должен быть /api/hashtag/hashtag.

И теперь вы получаете проблему: «основной» ресурс звучит точно так же, как служба.И мы ищем хорошее решение для этого.Есть ли лучшие практики для этого?

Спасибо!

Ответы [ 2 ]

0 голосов
/ 30 июня 2018

Основное назначение URL-имен: Ресурсно-ориентированная архитектура (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

Обратите внимание, что автомобилей (--plural)

Пример * * тысяча пятьдесят-две

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

Так что это даст ответ, подобный этому.

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

Надеюсь, вы получите базовые знания об соглашениях об именах REST.

0 голосов
/ 26 июня 2018

Рекомендуется называть службу как / api / serviceName / resource. Сказав, что вашей проблемой является имя службы.Одна вещь, которую мы использовали, это добавление Service к имени.Скажите UserService или OrderService.Я также видел имя как oms (для службы управления заказами) ims и т. Д. У вас может быть управление заказами / заказ или управление пользователями / пользователь.

Если это внутренний API, вы также можете продолжить.с некоторыми кодовыми именами для ваших услуг.

Или вы можете просто отпустить название службы.Ваша логика маршрутизации может быть полезной, но для внешних клиентов им действительно все равно, с кем они разговаривают.Вы можете оставить / api / заказать или / api / пользователя

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...