Глава 6: Проектирование API

[domage]

2025 год на дворе. Какой нахрен SOAP? Давайте тогда уж с CORBA начнем.

Перед тем как переводить источник, проверьте актуальность.

[trrerg]

Уважаемый @domage

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

SOAP в 2025: краткое обоснование актуальности

1. Почему SOAP еще используется?

• Стандартизация и надежность: строгая спецификация (XML, WSDL, WS-*), гарантированная доставка (например, через WS-ReliableMessaging).

• Безопасность: встроенные механизмы (WS-Security, цифровые подписи, шифрование), критично для госструктур и финансов.

• Совместимость: работает через HTTP/SMTP/JMS, поддерживается в legacy-системах (особенно в корпоративном секторе).

2. Примеры применения в 2025:

• Банки и платежи: межбанковские транзакции (SWIFT, ISO 20022), интеграция с mainframe.

• Госсектор: электронные госуслуги (например, налоговая отчетность в ЕС).

• Корпоративные ERP/CRM: SAP, Oracle E-Business Suite.

• Телеком: биллинговые системы (например, TM Forum стандарты).

• Авиация: бронирование билетов (Sabre, Amadeus).

3. Почему не умер?

• Legacy-системы: дорого переписывать (миллиардные бюджеты в банках).

• Юридические требования: например, PSD2 в ЕС допускает SOAP для API.

• Сложные workflow: там, где нужны транзакции и ACID (например, цепочки поставок).

Вывод: SOAP жив в нишах, где критичны безопасность и стандартизация, но для мобильных и cloud-сервисов чаще выбирают REST/gRPC.

[elena_habr]

Подскажите, пожалуйста, по вот этой фразе: "Другие утверждают, что нужно сохранять все плоским, включая связанные детали в данные для ресурса. В рамках этой парадигмы создание заказа требует отправки поля customer_id с деталями заказа.  " это метод альтернативный выражению /customers/5/orders/3 для получения 3го заказа 5го клиента. 1) Почему здесь используется метод POST? POST, а потом GET? 2) Их надо выполнять последовательно?