Оболочка SOAP/JMS как REST с использованием API Mgmt. инструменты практичны?

Question

Является оболочкой SOAP/JMS как RESTful API с использованием API Mgmt. инструменты практичны?

Инструменты управления API, такие как apigee и wso2 -am, требуют поддержки SOAP-сервисов как REST-JSON, но практически мне сложно сопоставить их и не видеть добавленную стоимость, которую мы можем предложить, обнажая все наши SOAP/JMS через Remy API API. инструмент. SOAP-услуги структурно сильно отличаются от REST, где вы можете иметь набор нескольких операций с возможной массой сопоставления элементов запроса и ответа для бизнес-кейсов.

REST с другой стороны основан на четырех HTTP-глаголах GET, POST, PUT и DELETE, которые должны обрабатываться тактично для обработки определенных ресурсов. Какой принцип проектирования мы можем использовать для отображения?

Например, для реализации вышеуказанного перевода может потребоваться добавление большого количества содержимого xml в ваш HTTP-заголовок для запроса GET и последующего его обработки, который не является стандартной реализацией HTTP и REST.

Спасибо, Wajid

Answer 1

Как сказал Ян, SOAP службы часто не отображаются непосредственно в RESTful API. Я не знаю никаких инструментов преобразования SOAP-REST, предоставляемых любым поставщиком, который автоматически создаст красивый API RESTful из набора SOAP-сервисов.

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

Затем, когда вы довольны API RESTful, используйте SOAP-сервисы в качестве строительных блоков.Уровень управления API должен, как пояснил Ян, помочь вам преобразовать вход RESTful в запросы SOAP, размять несколько вызовов, извлечь информацию из ответов в выбранные вами полезные данные и помочь вам защитить и масштабировать ваш API. Если вы обнаружите, что вам нужно идти на компромисс в дизайне API RESTful из-за невозможности компоновки строительных блоков SOAP в желаемый интерфейс RESTful, по крайней мере, вы поймете, где вы компрометируете.

Answer 2

Это отличный вопрос. REST - очень жестокое слово. Многие (возможно,) SOAP-сервисы являются транзакционными по своему характеру и поэтому не идеально подходят для парадигмы RESTful. Все, что было сказано, религиозные дебаты по использованию REST для сервисов RESTful немного глупые IMHO.

Для этого вы можете использовать продукт управления API (я работаю в компании по управлению API). По правде говоря, это редко так просто, как могут претендовать продавцы. Некоторые продукты могут декларативно опосредовать между SOAP и REST, но полученный RESTful-сервис, скорее всего, будет уродлив, вам, вероятно, потребуется удалить/добавить документ с SOAP-документами по краям вашего ответа и, по крайней мере, запросить документы. И когда вы начнете конвертировать XML < -> JSON, вы столкнетесь со всеми типами забавных вопросов с такими вещами, как Array, с последовательными сопоставлениями.

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

Если вы хотите получить дополнительную информацию по этому вопросу, не стесняйтесь сообщать мне. Я не думаю, что для меня было бы целесообразно предоставить рекламу моей компании на этом форуме.

Ян

Answer 3

Я не думаю, что это возможно автоматически, по крайней мере, не без ИИ.

Прежде всего вам нужно разделить каждое название операции на две части: ресурс с IRI и VERB.

Например:

• GetLastTradePrice будет по крайней мере GET /lastTradePrice или с последующим преобразованием GET tradePrices/last
• Hello будет GET /greeting?name="{name}"
• CreateUser, GetUserName, DeleteUserById будет POST /users, GET /users/{id}?fields="name", DELETE /users/{id}

Если вы хотите иметь хорошие IRI для отладки вашего маршрутизатора и ссылки на сервер-сервер-строитель, то для этого вам нужна строгая концепция или AI. Если нет, то вам повезло, что структура IRI не имеет особого значения, поэтому вы можете использовать /resources/{id} для каждого ресурса. Например, /users может быть /resources/static:1 и /users/123 может быть /resources/123. Если каждый ресурс имеет уникальный идентификатор в вашей системе. Если нет, то вам нужно использовать уникальные подкатегории, например /resources/avz5ag6u:123. Без искусственного интеллекта, или какой-либо строгой концепции именования в вашей службе SOAP, вы не сможете повторно использовать IRIs как /users по POST, GET или /users/{id} по PUT, GET, DELETE, но это не трагедия, поскольку покоем каждый ресурс может имеют несколько ИРИ. Просто имейте в виду, что они уникальны ...

Проблема со смысловой частью этих ссылок (VERB + IRI). С помощью REST вы просматриваете метаданные, относящиеся к ссылкам, например IANA link relations с vendor specific MIME types по HAL или rdf:Property, описанным заказчиком RDF vocab на Hydra (если речь идет о REST JSON ofc). Я думаю, что можно создать параметр валидации/описания параметра и возвращаемого значения из XSD, который у вас есть в вашем файле WSDL, но вам будет сложно найти метаданные ссылок. Для этого вам понадобится ИИ. Если вам повезло, ваш SOAP-сервис уже предоставляет некоторую информацию RDF, такой сервис, я думаю, что автоматическое сопоставление возможно, иначе я так не думаю, и в любом случае это будет тяжелая работа. Вы не сможете отлаживать или улучшать сгенерированную услугу, потому что в маршрутах будут использоваться анонимные IRI или шаблоны IRI.

Так что в большинстве случаев это невозможно сделать полностью автоматическим. Для вашего SOAP-сервиса вам понадобятся строгие концепции именования операций и/или уже существующие описания RDF. Думаю, даже с этим сложно написать генератор службы REST. Без этого вам нужно выполнить некоторую или более ручную работу, например, аннотировать вашу SOAP-службу с конкретными вещами REST или записать некоторые специфические атрибуты REST в ваш файл WSDL и использовать их для создания службы REST. Теперь это одна часть работы.

Другая часть - это повторное использование бизнес-логики вашего SOAP-сервиса.Если у вас есть центрированный макет, такой как чистые, луковые или шестиугольные/порты &, то его легко добавить новый адаптер для доставки или порта REST. Если вы не используете такую ​​архитектуру, вам необходимо вручную написать всю службу REST или адаптер REST класса Бога.

На мой взгляд, создание генератора SOAP -> REST не стоит усилий. Легче написать службу REST вручную.