- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
<name>customer_language_iso</name>
<value>
<string>en</string>
</value>
</member>
</struct>
</value>
</data>
</array>
</value>
</data>
</array>
</value>
</param>
</params>
недавно мне доводилось поработать с xml-выгрузкой из системы федерального масштаба, там был какой-то надмозг, который придумал транслитерировать половину атрибутов, да ещё и коряво (такие фантазёры, например, иногда, но не везде, русская X заменяется на x (икс), русская Р на p, а русская Ш на w, ну или "Kpy" - это сука "карточка персонального учета"), а половина, хоть и с английскими корнями, но вся в разных стилях
а в другом месте той же xsd выгрузки классификаторы перечислены сука "А", "Б6", "В", "Г", "ЧЖ", "ЖО", "ЖОБ"
просто удовольствие получил
Однако же SOAP на голову выше всяких RESTов, особенно для ЯП со статической типизацией.
Никогда не видели как дурачок кричит "SOAP это оверкилл, XML это говно, вот вам модный REST", а потом вручную документирует 150 методов, а потом с другой стороны такой же дурачок вручную пишет прокси на эти 150 методов, а потом половина из них не работает потому что "забыли обновить документацию".
Спрашиваешь: а нахуя????77
- Дык для тонких клиентов жы.
Но даже у них бардачилово с версиям / соответсвием документации.
У меня даже была конспирологическая версия искусственного завышения порога вхождения, чтобы отсечь проблемных в перспективе выпердышей-стартаперов.
К сожалению, такие компании встречаются редко
А потом кто-то в классе что-то меняет (поле добавляет или расширяет) и у всех всё ломается, если не обновить стабы.
То ли дело REST, где расширение ответа практически никогда ничего не сломает.
нет, если добавлять поле необязательным
с той же вероятностью можно и в ресте "исправить" сервер так, что тот перестанет принимать старый объект, т.к. в нем начнет не хватать обязательных для модели атрибутов
бывало поменяешь интерфейс (удалишь функцию, скажем) и все клиенты ломаются!