Что-то не так с наличием «одной» конечной точки для обслуживания нескольких «типов» запросов?

Question

Скажем, например, у меня есть служба доставки пиццы. Типы вещей, которые он может делать, например:

• CreateOrder
• CancelOrder
• GetOrderStatus

. Уровень API моей службы может представлять их как «отдельные» конечные точки, такие как /order (POST), /order (DELETE) и т. Д., И они каким-то образом направляются на рабочий уровень, который обрабатывает запросы.

Можно ли заставить работника получать запросы через одну очередь сообщений, в которой сообщения имеют вид

{
    id: "47a4aa26-295c-4163-9701-b6c20863643a",
    type: "order-create",
    payload: {
         size: "xl",
         toppings: ["canadianBacon", "pineapple"]
    }
}

и

{
    id: "4278dd527-6c4f-4bee-b8f6-0871af0b39ce",
    type: "order-cancel",
    payload: {
         orderId: "dff1b7e4-0c07-4327-8590-ac71065f32e5",
         cancellationDate: "Mon Oct 14 2019 09:24:20 GMT-0700 (Pacific Daylight Time)"
    }
}

вместо того, чтобы иметь разные type сообщения отправляются в «отдельную» очередь (или какой-либо другой тип «отдельной» абстракции / инфраструктуры, такой как тема при использовании Azure Service Bus).

Что мне нравится в этом, так этовсякий раз, когда есть новый тип бизнес-возможностей, который мне нужен для службы доставки пиццы, я просто определяю новый type и payload контракт и пишу новый обработчик, не нужно создавать какую-либо новую инфраструктуру / маршрутизацию / и т.д. .

Answer 1

Что-то не так с наличием «одной» конечной точки для обслуживания нескольких «типов» запросов?

Конечно, вы можете создать свою службу только с одной конечной точкой, но это неСтандартный способ!

Это означает, что вы упустите инструменты, созданные для поддержки конечных точек API. По сути, вам придется заново изобрести колесо, чтобы решить проблему устаревания API (в вашем случае - устаревание типа запроса) , проблему миграции стеков технологий или изменения полезной нагрузки, чтобы назвать несколько. Поскольку все серверные инфраструктуры следуют стандартным HTTP-спецификациям и принципам Restful, многие из вышеперечисленных проблем могут быть легко решены с помощью API-интерфейсов инфраструктуры, в противном случае вы можете найти тонны библиотек с открытым исходным кодом, которые помогут вам в этом.

Что мне нравится в этом, так это всякий раз, когда у меня есть новый тип бизнес-возможностей, который я хочу иметь в службе доставки пиццы, я просто определяю новый тип и контракт с полезной нагрузкой и пишу новый обработчик, не нужно создавать никакой новой инфраструктуры/routing/etc.

В прошлый раз, когда я проверял, определение новой конечной точки API стало довольно декларативным в наши дни, и framework генерирует инфраструктуру и код маршрутизации для вас. По крайней мере, когда я использовал Express, web-фреймворк nodejs, некоторое время назад.

Answer 2

Я думаю, что должны быть какие-то проблемы, если у вас есть несколько потребителей на рабочем уровне, а ваша очередь использует подход доставки по крайней мере один раз.