у SOAP довольно плохая репутация среди программистов. Однако можно было бы ожидать, что хотя бы в примитивных случаях он будет работать. Мне «повезло», что оба раза, когда я сталкивался с SOAP, он поворачивался ко мне крайними случаями.
пытаюсь сейчас использовать API Navteq, чтобы сообщать им о проблемах с данными. Одним инструментом сгенерировал из WSDL набор ява-классов (да, к сожалению, приходится делать на яве). Другим классным инструментом сравнительно просто допилил эти классы до состояния, когда можно-таки послать запрос. На всё ушло каких-то полдня. Застопорился я на том, что пароль к тестовому серверу не подходит, и пожаловался разработчикам API. Поскольку они сидят в Америке, ответ приходит на следующий день, если повезёт. Разработчики говорят: «мы тут всё меняем на серверах, используйте вот такой endpoint». Легко сказать, когда думаешь о доступе в терминах одного POST-запроса. А когда пытаешься использовать их технологию тем путём, что они сами рекомендуют, никто не даст тебе низкоуровневого доступа к адресу, который умные инструменты вынули из WSDL, скачанного с сервера. Напомнил про это разработчикам. А, говорят они, ну вот вам другой WSDL на другом тестовом сервере. «Так он же только из вашей сетки доступен!» — говорю. Молчат разработчики, думают.
К счастью, всё это пока что не так весело, как было в 2006 или 2007 году, когда МойКруг подключал AdSense, чтобы делиться доходами от рекламы с авторами постов. Казалось бы, AdSense — это Гугл, а Гугл — это крутые технари. Однако SOAP был и там. Причём опубликованный в WSDL интерфейс сервера не совпадал с реальным интерфейсом того же сервера. Чинить это Гугл отказывался, ибо это сломало бы доступ у ещё каких-то клиентов Гугла. В итоге пришлось забыть про красивые обещания SOAP, и собирать запросы вручную.
именно тогда мне попался на глаза один из лучших, на мой взгляд, образцов программистского юмора: «The S stands for Simple».
много лет назад кто-то придумал, что веб-технологии уже достаточно продвинуты, чтобы делать не только веб-сайты, но и веб-приложения. Так у них и повелось. Однако веб-приложения продолжали отличаться от обычных приложений, в первую очередь тем, что работали только в браузере.
многие пытались исправить это, начиная с Mozilla Prizm, продолжая виджетами Оперы и приложениями Хрома. Кажется, верхом интеграции тут стало использование favicon сайта в качестве иконки приложения. Мобильные платформы были ещё более разнообразны, чем у больших компьютеров, поэтому там веб-приложениям прочили ещё более успешное будущее. Кажется, под первые айфоны этот способ разработки приложений предполагался вообще единственным. В итоге в смартфонах ситуация такая же, как и на десктопе.
многие идут путём PhoneGap: завернуть веб-приложение в обёртку, которая выдает ему необходимые API. Кажется, это всё равно не очень популярно, как и Адобовский вариант обернуть всё в Air.
конечно, большинству мелких разработчиков это сделать сравнительно несложно. А вот крупным компаниям типа Нокии этот путь очень не нравится: а вдруг посудиться захочется? Поэтому с приходом Chrome 21 плагин для трёхмерных карт Нокии в хром будет ставиться доисторическим способом: скачайте и запустите setup.exe. До тех пор, конечно, пока мы закончим наши WebGL-карты.
в продолжение давней темы о глючности браузеров. Пишешь-пишешь себе код, полагающийся на history.state, а потом оказывается, что в рассвежайшей версии модного браузера Google Chrome это свойство вообще не поддерживается. Оно появляется только в событиях смены состояния. Приходится изобретать хаки. А те, кто в хроме пишут, скорее всего и не заметили бы.
но вот почему интернет не полнится стенаниями на тему сломанного уже несколько версий автодополнения по <Tab> в консоли хрома, я не понимаю. Это же нельзя не заметить, каждый раз приходится тянуться к самой дальней кнопке — стрелке вправо