Какой лучший способ предложить SOAP / XML + REST / JSON?

Question

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

У меня уже есть хороший API Java Services, и я хочу предоставить фасад веб-служб поверх этого.

По обеим сторонам дебатов о SOAP и REST есть веские аргументы, и меня интересует, есть ли простой способ предложить оба варианта? Не обязательно в одно и то же время одновременно для одного и того же развертывания (хотя это может быть неплохо) ... скорее, чтобы предложить выбор клиентам.

Answer 1

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

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

Создание конечных точек HTTP для каждого метода - это то, что некоторые люди считают достаточным для создания конечной точки RESTful., но это не так.Однако создание таких конечных точек HTTP все еще может иметь для вас смысл, и в этом случае вы должны пойти дальше и найти структуру, обеспечивающую это.

Причина, по которой мой ответ начинается с "Нет, нет", заключается в том, чтодля создания интерфейса REST недостаточно публиковать конечные точки HTTP, вам нужно проделать гораздо больше работы:

• поиск типов мультимедиа для повторного использования
• поиск связей для повторного использования
• проектирование ваших собственных типов мультимедиа
• определение ваших собственных связей ссылок

И в мире нет структуры, которая бы принимала произвольный список сигнатур функций и выполняла этичетыре вещи для тебя.Фреймворки позволяют вам использовать больше HTTP, чем SOAP (например, OAuth, OpenID, кэширование, идемпотентность), но они не ведут вас полностью к REST.

Answer 2

Да, вы можете предложить оба варианта (и я бы порекомендовал это сделать). Вы можете решить, в каком формате должен быть ответ, основываясь на заголовке HTTP Accept (application/soap+xml против application/json) или на параметре пользовательского запроса (например, http://example.com/myapi?fmt=soap против http://example.com/myapi?fmt=json). В любом случае вам нужно иметь четкое значение по умолчанию, если клиент не указал явно желаемый формат ответа.

Вы можете также рассмотреть возможность добавления формата ответа REST / POX, с дополнительными расширениями Atom + в качестве контейнера ответов. (application/atom+xml и http://example.com/myapi?fmt=atom для двух вышеуказанных методов)

Answer 3

Вкратце, одна служба WCF может предлагать несколько конечных точек для одного и того же контракта на обслуживание. Один может быть REST, другой может быть SOAP / XML, другой может быть TCP / IP + двоичный.

Answer 4

Я не очень заинтересован в мыльных веб-сервисах, но гуглюсь и обнаружил, что платформа Axis 2 от apache не только обеспечивает SOAP 1.1 и SOAP 1.2, но и REST / POX с той же реализацией бизнес-логики.Вы можете увидеть больше информации:

http://ws.apache.org/axis2/

Answer 5

Я бы придерживался простого решения REST. У Amazon есть и REST, и SOAP apis для одних и тех же сервисов, и сервисы REST используются 85% времени, поэтому, если у вас нет особой потребности в SOAP, я бы не стал ее реализовывать.