Каков рекомендуемый способ определения шаблонов URL и управления версиями для серверных служб и определений API в WSO2 API Manager - PullRequest
Новая
       8

Каков рекомендуемый способ определения шаблонов URL и управления версиями для серверных служб и определений API в WSO2 API Manager

0 голосов
/ 11 декабря 2018

Мы столкнулись с проблемой при включении наших служб приложений Java в WSO2 API Manager.Наши типичные серверные приложения работают на Tomcat и имеют контекстный путь, например (/ customer-manager).Контроллеры Spring определяют конечные точки в следующем формате: /api/VERSION/resource, например: /api/v1/customers, /api/v2/customers и т. Д.

Таким образом, наши вызовы бэкэнда выглядят так: http://localhost:8080/customer-manager/api/v1/customer.Наша автоматически сгенерированная документация swagger публикует информацию о пути REST как /customer-manager/api/v1/customers.

. Теперь, когда мы создаем определение API в WSO2, мы вынуждены указать путь к контексту и версию (/ customer-manager, v1) иэта информация добавляется к вызовам API, поэтому наши вызовы API WSO2 выглядят следующим образом:

https://WSO2_HOST:WSO2_PORT/customer-manager/v1/customer-manager/api/v1/customers.

Как видите, путь к контексту и версия дублированы .

Так что возникает несколько вопросов:

  • Мы могли бы заставить наши фоновые приложения избавиться от своего собственного пути контекста и развернуть их как единственное приложение в Tomcat (ROOT.war). Ожидается ли, что у серверных приложений нет контекстного пути?

  • Чтобы не дублировать версию, мы также можем удалить ее из нашего серверного приложения., теперь с более красивыми URL: https://WSO2_HOST:WSO2_PORT/customer-manager/v1/api/customers.Но в случае бэкэнд-приложения, поддерживающего две одновременные версии API, как мы можем различить, какая бэкэнд-конечная точка должна их обрабатывать? Обратите внимание, что при предыдущем подходе у нас было два бэкэнд-отображения /api/v1/customers и /api/v2/customers и было ясно, какой из них будет обрабатывать версионный вызов.

1 Ответ

0 голосов
/ 12 декабря 2018

Наличие контекста и версии версии в URL-адресе бэкэнда является нормальным, и не всегда возможно удалить их из бэкэнда.Рассматривая вопрос, я предполагаю, что вы пытаетесь опубликовать API, используя файл чванства.Возможно, вам нужно проверить, почему определение чванства устанавливает «/ customer-manager / api / v1 / Customers» в качестве пути отдыха (ресурса).Если вы можете обновить серверную часть, указав «/ customer-manager / api /» в качестве базового пути и «customer» в качестве ресурса, повторяющихся контекстных путей можно избежать.

В этом случае вы можете создать API со следующими параметрами: 

Name: customer-manager
Context: /customer-manager/api
Version: v1
Resource: customers (This will be identified through Swagger definition)
Backend URL: http://localhost:8080/customer-manager/api/v1

Если изменение определения чванства невозможно, вы можете просто создать определение API в API Manager, определивресурс, как я уже упоминал выше, вместо использования опции на основе Swagger.В этом случае вы можете использовать Разработка нового REST API .

...