Comments 206
Спасибо, автор
Спасибо благодарному читателю, осилившему пост :)
Я как опубликовал — увидел какого нереального размера оно получилось :)
Я как опубликовал — увидел какого нереального размера оно получилось :)
Пост классный. А размер — самое то, кому интересно всё равно дочитает
Уважаемый, почему статья до сих пор в личном блоге? Нужно срочно исправлять. :)
Читается отлично несмотря на размер, так что благодарных читателей должно быть много.
Размер не имеет значения когда так обстоятельно и понятно всё разложено по полочкам. Спасибо.
UFO just landed and posted this here
Дело, как говорится, не в размере, а в том, как этим размером пользуешься. Здесь автор с большой отдачей использовал весь объем статьи. На самом деле, одна из немногих длинных статей, которые я без напряга дочитал до конца.
Многим надавили на хронический «синяк» ;) Давите сильнее, чаще, безжалостнее!
Автор, вы мой герой дня. Думаю не не одному нужна была такая встряска.
Добавлю про SOAP — одним из плюсов работы с веб-сервисами является то, что на основе WSDL (Web Services Description Language) для очень многих языков существуют генераторы так называемых «прокси классов». Это когда по WSDL генерируется код сложных объектов параметров и код для вызова методов веб-сервиса так, как будто это локальные вызовы методов веб-сервиса.
и для двух языков которые в основном хостят веб-сервисы (.NET, Java) есть замечательные технологии для генерации серверной части веб-сервиса. Очень удобно.
WSDL,SOAP
Ересь, после пары 10мб cхем вам действительно захочется выкинуть их — и это правильно
А грамотное api — это не то когда — Запущу это программму, она сгенерит это — я скормлю этому а потом запрошу вот это — и с помощью вот той либы я получу нужный мне ответ
и весь WS-
это решение несуществующей задачи
/
rest — лучшее решение
Ересь, после пары 10мб cхем вам действительно захочется выкинуть их — и это правильно
А грамотное api — это не то когда — Запущу это программму, она сгенерит это — я скормлю этому а потом запрошу вот это — и с помощью вот той либы я получу нужный мне ответ
и весь WS-
это решение несуществующей задачи
/
rest — лучшее решение
Так в том-то и дело, что не нужно этим мучать себя мегабайтами XML-я — пусть этим займутся машины.
А задача более чем жизненная — я привел пример.
Мне понадобилось ровно 3 строчки, чтобы сделать нужное.
С rest-ом так быстро и просто получится?
А задача более чем жизненная — я привел пример.
Мне понадобилось ровно 3 строчки, чтобы сделать нужное.
С rest-ом так быстро и просто получится?
извините, я согласен с теми кто вам благодарен, хорошая статья и вы все правильно рассказываете, но потом вдруг вы демонстрируете пример и мне перестает нравится. да может быть вам нравится подключить библиотеки и вы рады что для вашего любимого языка она есть, но «чистый» (если я правильно понял смысл так как вы его описывали) rest — имхо всетаки лучше. Я даже не знал до прочтения вашей статьи что это так называется, но давно тяготею к такому подходу.
Я не хочу подключать этот soap даже если билиотека для php есть, ибо меня подташнивает от всего этого корпоративного кода который я подключаю и не дай бог туда забрести во время отладки потом.
может я один такой конечно, но соап повторит судьбу корбы — я пошлю его подальше.
Я не хочу подключать этот soap даже если билиотека для php есть, ибо меня подташнивает от всего этого корпоративного кода который я подключаю и не дай бог туда забрести во время отладки потом.
может я один такой конечно, но соап повторит судьбу корбы — я пошлю его подальше.
Зависит от технологии. В ADO.NET Data Services (реализация REST от Microsoft) это также легко как с SOAP.
Вы путаете. REST не лучше, REST — просто другой.
— XML-RPC — императивный вызов процедур в чистом виде
— REST — обращения к децентрализованным ресурсам (именно к источникам данных, а не к объектам/методам) в сегменте http.
— SOAP — императивный messaging и прочее, в том числе ассинхронное.
По крайней мере, пока что это так.
— XML-RPC — императивный вызов процедур в чистом виде
— REST — обращения к децентрализованным ресурсам (именно к источникам данных, а не к объектам/методам) в сегменте http.
— SOAP — императивный messaging и прочее, в том числе ассинхронное.
По крайней мере, пока что это так.
REST существенно проще для понимания.
А кроме простоты понимая + удобства использования(что очень рядом) что еще нужно от api?)
Мне кажется, что REST проще вначале — его проще понять, но работать потом проще с SOAP+WSDL.
Что может быть проще написать 2 строки инициализации, и дальше использовать как локальную либу?
Что может быть проще написать 2 строки инициализации, и дальше использовать как локальную либу?
WSDL хорош для сложных задач — когда есть двухсторонний обмен данными, однако требует погружения в тему. Предложение использовать WSDL вгонит в ступор разработчика средней руки :-(.
Для задачах получения данных по запросу REST — самое то: просто, дешево и работает :-).
REST позволяет:
— делать массовые решения (а значит понятные болшинству с не высокой ценой);
— эффективно кэшировать данные и выдерживать высокие нагрузки.
Если честно, то я не знаю ни одного массового использования WSDL, так, чтобы тысячи сайтов использовали такое API.
При этом все мы знаем такие примеры для REST: amazon.com, facebook, twitter. Из российских — cbr.ru
Для задачах получения данных по запросу REST — самое то: просто, дешево и работает :-).
REST позволяет:
— делать массовые решения (а значит понятные болшинству с не высокой ценой);
— эффективно кэшировать данные и выдерживать высокие нагрузки.
Если честно, то я не знаю ни одного массового использования WSDL, так, чтобы тысячи сайтов использовали такое API.
При этом все мы знаем такие примеры для REST: amazon.com, facebook, twitter. Из российских — cbr.ru
На западе WSDL применяется там, где финансовые транзакции транзакции: биржи, банки.
Пример масштабного проекта — биржа ставок BetFair. API реализовано на SOAP поверх HTTPS.
Пример масштабного проекта — биржа ставок BetFair. API реализовано на SOAP поверх HTTPS.
SOAP хорош, когда надо быстро организовать RPC-взаимодействие с простыми типами данных аргументов/результатов между конкретными экземплярами ПО. ЕМНИП, когда я последний раз игрался с SOAP как со схемой, даже дотнетовские компоненты довольно специфически понимали XML Namespaces.
Т.е. реально смысл фразы «реализовать SOAP-интерфейс» — это «реализовать интерфейс для RPC-вызовов из дотнета». А вот когда приходится делать усложнения, например, привязывать шифрование к конкретным запросам (ws-security, иначе серверу придётся привязываться к информации об SSL`е от веб-сервера) наступает совсем тяжко.
Т.е. реально смысл фразы «реализовать SOAP-интерфейс» — это «реализовать интерфейс для RPC-вызовов из дотнета». А вот когда приходится делать усложнения, например, привязывать шифрование к конкретным запросам (ws-security, иначе серверу придётся привязываться к информации об SSL`е от веб-сервера) наступает совсем тяжко.
Да, ws-security — вещь в себе.
Я видел упощенное решение в таком виде: человек авторизуется логином паролем, получает некий токен (по сути — куку сессии) и дальше указывает эту куку в каждом запросе.
Я видел упощенное решение в таком виде: человек авторизуется логином паролем, получает некий токен (по сути — куку сессии) и дальше указывает эту куку в каждом запросе.
По такой схеме работал с веб-сервисом компании NAVTEQ (назывался не куку сесии, просто ticket), только им GPS координаты. Visual Studio указал url сервиса, студия сгенерировала прокси-класс и мне осталось только написать две строчки по работе с сервисом используя два основные методы GET и SET. И все никаких тебе xml схем на мегабайты я не рисовал и не парсил в голове!
UFO just landed and posted this here
Теория хороша, конечно. Но ситуации когда либы работы с мылом не дружат и надо смотреть реальные сообщения и работать над ними напильником вполне себе регулярны. Тогда концепцией REST проникаешься сразу и нафиг.
Да уж, граблей там разложено слишком дофига. Важные детали не стандартизованы. Приходится то допиливать [де]сериализаторы, то разбираться с кривыми серверами, использующими свой ip-адрес в качестве xmlns, то еще с чем-нибудь бороться.
Кривая реализация может встретиться везде.
Да кто ж спорит. Но SOAP отлаживать особенно сложно.
Мне кажется, что в SOAP все будет более надежная система — потому что жестко формализованы (в XML Schema) запрос и ответ — то есть, если вам с того конца отправили неверный ответ, то вы получите ошибку, а не бредятину.
А вот в REST вам вместо инфо об аэропорте могут легко прислать картинку :)
А вот в REST вам вместо инфо об аэропорте могут легко прислать картинку :)
content-type negotiation
WSDL — это просто описание, оно может точно так же не соответствовать реальности, как и документация к REST-сервису. Так что картинку вместо информации об аэропорте можно неожиданно получить и в SOAP (и наверняка найдутся WS-клиенты, которые эту картинку попробуют отдать программе под видом аэропорта).
Именно! В точку. Поэтому протоколы и строятся всеми максимально простыми. Всеми, кроме MS…
UFO just landed and posted this here
Нихрена не понял. Общественность считает что сложный протокол легче в отладке или что SOAP/WSDL относятся к простым?
Ну почему же сразу про MS? А как же, например, IBM? У них тоже есть своя реализация SOAP. И проблема не в кривизне, а в несовместимости этих реализаций. В рамках одной платформы все работает хорошо. Если говорить про MS — при использовании с обеих сторон
именно.
простые сисемные администраторы выбирают REST.
нам бы что б работало.
пример автора поста не заработал.
ошибка WSDLError: No address binding found in port.
вылетело со строчки 3
python2.5 ZSI-2.0_rc3
что вполне ожидаемо когда видишь слова WSDL ;)
простые сисемные администраторы выбирают REST.
нам бы что б работало.
пример автора поста не заработал.
ошибка WSDLError: No address binding found in port.
вылетело со строчки 3
python2.5 ZSI-2.0_rc3
что вполне ожидаемо когда видишь слова WSDL ;)
Что именно не сработало? Напечатайте подробно ошибку.
/opt/local/lib/python2.5/site-packages/ZSI-2.0_rc3-py2.5.egg/ZSI/wstools/WSDLTools.py in getAddressBinding(self)
1114 return item
1115 raise WSDLError(
-> 1116 'No address binding found in port.'
1117 )
1118
1114 return item
1115 raise WSDLError(
-> 1116 'No address binding found in port.'
1117 )
1118
боюсь что это нормально.
некоторое время назад была задача подружить perl и python подсистемы через SOAP.
Под перл нашелся неплохо поддерживаемая SOAP::Lite, а вот найти хорошую, не заброшенную либу для python оказалось проблемой. Пришлось допиливать какой-то древний SOAPy то ли SOAPpy для того чтобы он принимал и отправлял сессионную куку от SOAP сервера.
некоторое время назад была задача подружить perl и python подсистемы через SOAP.
Под перл нашелся неплохо поддерживаемая SOAP::Lite, а вот найти хорошую, не заброшенную либу для python оказалось проблемой. Пришлось допиливать какой-то древний SOAPy то ли SOAPpy для того чтобы он принимал и отправлял сессионную куку от SOAP сервера.
Я использовал
Python 2.5.2 (r252:60911, Jan 4 2009, 21:59:32)
ZSI.version.Version (2, 1, 0)
Python 2.5.2 (r252:60911, Jan 4 2009, 21:59:32)
ZSI.version.Version (2, 1, 0)
я ZSI 2.0 rc3 получил by easy_install
remote_data = urllib.urlopen(«https://user:password@host/rest/vm/list»)
vm_list = simplejson.loads(remote_data.read())
примерно так я получаю список виртульных машин с Enomalism2 по http
а что бы то же самое с SOAP и VMWare пришлось изрядно заморочиться.
изрядно.
remote_data = urllib.urlopen(«https://user:password@host/rest/vm/list»)
vm_list = simplejson.loads(remote_data.read())
примерно так я получаю список виртульных машин с Enomalism2 по http
а что бы то же самое с SOAP и VMWare пришлось изрядно заморочиться.
изрядно.
Год назад пытался найти работающую библиотеку на Javascript для работы с SOAP, отчаявшись решил написать свой парсер WSDL. Через пару дней понял, что сильно недооценил задачу и под натиском сроков просто перешли на REST.
А чего в личный блог-то написал? Посту место на главной и в тематическом блоге.
Пост превосходен. А то заладили — SOAP то, SOAP се, даже те, кто его в глаза не видали.
В качестве внешнего API, пожалуй, и стоит отдавать SOAP. Но для связки внутри сервисов одного проекта он не очень кандидат, — достаточно много ресурсов отъедает на парсинг/генерацию XML.
Это да, весь этот лохматый ХМЛ сьест немало ресурсов.
Тут получается, что WSDL+SOAP — это универсальное и простое решение для внешнего пользователя, желающего интергироваться с вашей системой. Он абстрагирован от всего, чего можно, даже от транспорта — существуют варианты SOAP-over-SMTP, SOAP-over-FTP,…
Для внутреннего использования он слишком избыточен и абстрактен — там лучше более конкретные протоколы, где-то даже бинарные.
Тут получается, что WSDL+SOAP — это универсальное и простое решение для внешнего пользователя, желающего интергироваться с вашей системой. Он абстрагирован от всего, чего можно, даже от транспорта — существуют варианты SOAP-over-SMTP, SOAP-over-FTP,…
Для внутреннего использования он слишком избыточен и абстрактен — там лучше более конкретные протоколы, где-то даже бинарные.
UFO just landed and posted this here
JSON мне милее, чем XML. Почему его даже не упомянули? (
JSON — это формат кодирования сообщения.
Я указал его как возможный вариант в REST.
Я указал его как возможный вариант в REST.
кстати json-rpc.org/
Я понял, что я — идиот и тут несколько другое. )
во-первых, хочу уточнить про PUT/POST в REST, а то в посте они перепутаны. PUT — создание, POST — обновление
во-вторых, WS-* кажется мягким и шелковистым до тех пор, пока не влезаете в legacy код, и не начинаете разгребать чужие грабли. Вот тогда вам придётся собирать эти дикие запросы руками, и вы быстро разлюбите эту семейку протоколов. И не надейтесь, что legacy код бывает только у идиотов, с которыми вам не придётся работать — я лично бился с API не какой-то шарашкиной конторы, а самого Google, у которого WSDL не соответствовал реальности, а обновить они его не могли. Очень было весело… Такая психология «инструменты всё сделают за нас» была очень популярна в первые годы XML, но довольно быстро сошла на нет. Далеко не всегда инструменты защитят вас от кромешного ужаса.
для меня самым ярким примером глупости WS-* было то, что в нём есть аналог HTTP, при том, что сам WS-* работает на HTTP. Получается такой HTTP-over-HTTP.
а, пожалуй, решающий аргумент за REST состоит в том, что он на порядки лучше интегрируется в веб, потому что он и есть веб — его очень просто, легко и эффективно кешировать, балансировать, шардить и прочая, и прочая — и всё это существующим дешёвым железом общего назначения. У нас есть перед глазами пример интернета — невероятно успешной огромной сети, и HTTP — одна из главных причин такой её масштабируемости. Глупо выбрасывать работающий и надёжно проверенный инструмент. Пользуйтесь HTTP, а не WS-*/SOAP
я не буду дальше в комментах что-то доказывать, просто для пользы хабра хочу, чтобы тут были эти слова
во-вторых, WS-* кажется мягким и шелковистым до тех пор, пока не влезаете в legacy код, и не начинаете разгребать чужие грабли. Вот тогда вам придётся собирать эти дикие запросы руками, и вы быстро разлюбите эту семейку протоколов. И не надейтесь, что legacy код бывает только у идиотов, с которыми вам не придётся работать — я лично бился с API не какой-то шарашкиной конторы, а самого Google, у которого WSDL не соответствовал реальности, а обновить они его не могли. Очень было весело… Такая психология «инструменты всё сделают за нас» была очень популярна в первые годы XML, но довольно быстро сошла на нет. Далеко не всегда инструменты защитят вас от кромешного ужаса.
для меня самым ярким примером глупости WS-* было то, что в нём есть аналог HTTP, при том, что сам WS-* работает на HTTP. Получается такой HTTP-over-HTTP.
а, пожалуй, решающий аргумент за REST состоит в том, что он на порядки лучше интегрируется в веб, потому что он и есть веб — его очень просто, легко и эффективно кешировать, балансировать, шардить и прочая, и прочая — и всё это существующим дешёвым железом общего назначения. У нас есть перед глазами пример интернета — невероятно успешной огромной сети, и HTTP — одна из главных причин такой её масштабируемости. Глупо выбрасывать работающий и надёжно проверенный инструмент. Пользуйтесь HTTP, а не WS-*/SOAP
я не буду дальше в комментах что-то доказывать, просто для пользы хабра хочу, чтобы тут были эти слова
Спасибо за интересный коммент.
По методам: мне попадались разные варианты, и на, мой взгляд, по названию PUT тоже больше подходит для создания.
Я считаю, что любой инструмент надо поддерживать в порядке. Кривой WSDL — кривой интерфейс. Проблема часто решается так: делается несколько версий API, и разные версии WSDL. Это удобно тем, что вы для себя раз и навсегда можете зафиксировать интерфейс, при этом компания может выпускать новые версии.
Да, WSDL сильно абстрактен и избыточен — но вы его можете гонять даже по FTP или почте.
Угу. Обратите внимание на выбор инструментов: массовые сервисы с невысокими требованиями к надежности (типа соц. сетей) выбирают REST — с ним нагрузка меньше. А вот где идет работа с деньгами (биржи, платежные системы) предпочитают SOAP.
По методам: мне попадались разные варианты, и на, мой взгляд, по названию PUT тоже больше подходит для создания.
Я считаю, что любой инструмент надо поддерживать в порядке. Кривой WSDL — кривой интерфейс. Проблема часто решается так: делается несколько версий API, и разные версии WSDL. Это удобно тем, что вы для себя раз и навсегда можете зафиксировать интерфейс, при этом компания может выпускать новые версии.
Да, WSDL сильно абстрактен и избыточен — но вы его можете гонять даже по FTP или почте.
Угу. Обратите внимание на выбор инструментов: массовые сервисы с невысокими требованиями к надежности (типа соц. сетей) выбирают REST — с ним нагрузка меньше. А вот где идет работа с деньгами (биржи, платежные системы) предпочитают SOAP.
+1
имхо, именно поэтому фраза «мы сделали как твиттер — дали REST-подобный интерфейс» выглядит не так уж и глупо.
имхо, именно поэтому фраза «мы сделали как твиттер — дали REST-подобный интерфейс» выглядит не так уж и глупо.
> Далеко не всегда инструменты защитят вас от кромешного ужаса.
С некоторых пор у меня сложилось впечатление, что именно они ведут к этому ужасу. Плавно сложилось впечатление, что минимум проблем имеет народ строющий запросы шаблонными движками и разбирающий самописными анализаторами. А супер-(де)сериализаторами, биндилками и валидаторами и прочей халявной атоматикой вымощена дорога в ад :(
> для меня самым ярким примером глупости WS-* было то, что в нём есть аналог HTTP, при том, что сам WS-* работает на HTTP. Получается такой HTTP-over-HTTP.
Не стоит забывать что SOAP делался для широкого круга транспортных протоколов, в частности вполне проработана его реализация на основе SMTP. Отсюда некоторое перекрытие с функциями HTTP.
С некоторых пор у меня сложилось впечатление, что именно они ведут к этому ужасу. Плавно сложилось впечатление, что минимум проблем имеет народ строющий запросы шаблонными движками и разбирающий самописными анализаторами. А супер-(де)сериализаторами, биндилками и валидаторами и прочей халявной атоматикой вымощена дорога в ад :(
> для меня самым ярким примером глупости WS-* было то, что в нём есть аналог HTTP, при том, что сам WS-* работает на HTTP. Получается такой HTTP-over-HTTP.
Не стоит забывать что SOAP делался для широкого круга транспортных протоколов, в частности вполне проработана его реализация на основе SMTP. Отсюда некоторое перекрытие с функциями HTTP.
Ничего как раз не перепутано. Создание — POST, обновление — PUT
По определению HTTP (пример смотреть на www.w3.org/Protocols/rfc2616/rfc2616-sec9.html):
GET, HEAD, PUT, DELETE — Идемпотентныe методы. т.е. повторное их выполнение не должно визывать изменений состояния ресурса. Сколко ресурсу не говори «PUT тебя зовут вася» – один, два или десять раз – резултат один :)
POST — повторный вызов может привести к нежелательным резултатам (например создать несколко новых ресурсов).
По определению HTTP (пример смотреть на www.w3.org/Protocols/rfc2616/rfc2616-sec9.html):
GET, HEAD, PUT, DELETE — Идемпотентныe методы. т.е. повторное их выполнение не должно визывать изменений состояния ресурса. Сколко ресурсу не говори «PUT тебя зовут вася» – один, два или десять раз – резултат один :)
POST — повторный вызов может привести к нежелательным резултатам (например создать несколко новых ресурсов).
Отличный пост, спасибо!
Дайте ссылку на пост про «очередной велосипед».
я, конечно, придираюсь, но «тавтология» пишется через «в»
А за пост спасибо!
А за пост спасибо!
API — «он» («интерфейс»), а не «оно»
Ну в немецком вполне себе даже «оно» :))
Написано заглавными и латинскими, потому что является английской аббревиатурой, а имеет средний род, потому что по-русски читается как «апи» и имеет все признаки среднего, а не мужского рода.
Почему тогда не множественного числа и не глагола? :)
Если бы мы использовали в качестве сказуемого, то был бы глагол, но в данной форме («апи») не имел бы признаки глагола.
А тут слово «апи» вполне себе существительное, и, так как, мы его используем в качестве описания одной сущности, то единственное число, если бы мы говорили про несколько «API», было бы множественное.
А тут слово «апи» вполне себе существительное, и, так как, мы его используем в качестве описания одной сущности, то единственное число, если бы мы говорили про несколько «API», было бы множественное.
Это какие же признаки среднего рода имеет слово API?
Если мы используем какое-либо слово в русском тексте, то читать его будут по-русски.
Получается, что написано «API», а читается как «апи», что устоялось уже в русской речи в технических кругах.
Морфологические признаки прямо сейчас точно не приведу, но в этой статье немного про рода написано. Например, там есть такая фраза: «Иноязычные существительные чаще относятся к среднему роду (кафе, меню, ателье)». Так написано не потому, что слова иностранные, а потому что большое количество иностранных слов похожи на русские слова среднего рода.
Получается, что написано «API», а читается как «апи», что устоялось уже в русской речи в технических кругах.
Морфологические признаки прямо сейчас точно не приведу, но в этой статье немного про рода написано. Например, там есть такая фраза: «Иноязычные существительные чаще относятся к среднему роду (кафе, меню, ателье)». Так написано не потому, что слова иностранные, а потому что большое количество иностранных слов похожи на русские слова среднего рода.
Чтение API как «апи» устоялось. Вот только «АПИ», блин, это «интерфейс» — он.
Так же как «кофе» — «напиток», он.
Это только «Фурсенко» — оно.
З.Ы. Не, ну можно даже ради интереса посравнивать через тот же яндекс частоту словосочетаний «новый апи» vs «новое апи», «удобный API» vs «удобное API», «новый API» vs «новое API»
Так же как «кофе» — «напиток», он.
Это только «Фурсенко» — оно.
З.Ы. Не, ну можно даже ради интереса посравнивать через тот же яндекс частоту словосочетаний «новый апи» vs «новое апи», «удобный API» vs «удобное API», «новый API» vs «новое API»
Предположим, что я прав и по всем признакам это слово среднего рода, тогда вы будете сравнивать реальность и формальность.
Со временем они взаимопроникают, но в какой-то конкретный момент времени имеют более-менее чёткие границы по отношению как к конкретному слову, так и к определённым группам.
Т. е. вы не сможете ничего доказать частотой, имхо.
ЗЫ Большая часть людей говорит «звОнят» вместо «звонЯт», но на язык одномоментно это не влияет. Возможно, лет через 20 это станет нормой.
Здесь другая ситуация: апи — не словарное слово. Поэтому все склоняют как хотят, и как приживётся, так и будет.
ЗЗЫ Ещё один пример — «бьеннале» или «биеннале». Говорят, что это «выставка», поэтому «она».
На самом деле, можно «биеннале» перевести и как «фестиваль», тогда будет уже «он». Вот здесь и кроется засада. Кто-то автоматом берёт род перевода, а кто-то устанавливает род, чувствуя язык. Т. е. если взять само слово не зная его смысла, то получится «оно».
Первоначальный вариант уже начал изменяться («бьеннале» → «биеннале»), обретая более родные для русского языка черты. Со временем, как слово станет самостоятельным, скорее всего, обретёт и свой род.
Со временем они взаимопроникают, но в какой-то конкретный момент времени имеют более-менее чёткие границы по отношению как к конкретному слову, так и к определённым группам.
Т. е. вы не сможете ничего доказать частотой, имхо.
ЗЫ Большая часть людей говорит «звОнят» вместо «звонЯт», но на язык одномоментно это не влияет. Возможно, лет через 20 это станет нормой.
Здесь другая ситуация: апи — не словарное слово. Поэтому все склоняют как хотят, и как приживётся, так и будет.
ЗЗЫ Ещё один пример — «бьеннале» или «биеннале». Говорят, что это «выставка», поэтому «она».
На самом деле, можно «биеннале» перевести и как «фестиваль», тогда будет уже «он». Вот здесь и кроется засада. Кто-то автоматом берёт род перевода, а кто-то устанавливает род, чувствуя язык. Т. е. если взять само слово не зная его смысла, то получится «оно».
Первоначальный вариант уже начал изменяться («бьеннале» → «биеннале»), обретая более родные для русского языка черты. Со временем, как слово станет самостоятельным, скорее всего, обретёт и свой род.
Одно из правил:
«К существительным среднего рода относятся: существительные с окончанием -о (-е) в именительном падеже единственного числа; десять слов на -мя: имя, время, племя, знамя, бремя, семя, стремя, темя, пламя и вымя; слово дитя.» (отсюда).
Про саму морфологию — здесь.
В общем, я не филолог и мне сложно привести точное правило.
Пока нашёл такое:
«Несклоняемые имена существительные, попадая в русский язык или образуясь в нем, должны приобрести родовую характеристику, которая будет проявляться только при выборе согласованных с существительным прилагательных, причастий и глаголов.
Существуют следующие закономерности выбора такими существительными родовой характеристики: род зависит либо от значения слова, либо от рода другого русского слова, которое рассматривается как синоним или как родовое наименование для данного неизменяемого слова. Для разных групп существительных ведущими являются разные критерии.
Если существительное обозначает предмет, то оно обычно приобретает характеристику среднего рода: пальто, кашне, метро. Однако женского рода авеню (так как улица), кольраби (так как это капуста), кофе — с колебанием — мужской / средний, мужской род — пенальти, евро.»
На самом деле, язык живой и что-то приживается так, что-то эдак.
Но пример с кофе, мне кажется, показательный: кофе дали несвойственный ему мужской род, а со временем слово обжилось и приобрело более точный для языка средний.
Хотя, бывает и обратное — изначально верные слова начинают использовать неправильно, не взирая при этом на все правила и признаки.
Больше по существу сказать не готов.
По ощущениям апи — оно.
У вас может быть другое мнение. Это не противозаконно и даже хорошо, что так.
«К существительным среднего рода относятся: существительные с окончанием -о (-е) в именительном падеже единственного числа; десять слов на -мя: имя, время, племя, знамя, бремя, семя, стремя, темя, пламя и вымя; слово дитя.» (отсюда).
Про саму морфологию — здесь.
В общем, я не филолог и мне сложно привести точное правило.
Пока нашёл такое:
«Несклоняемые имена существительные, попадая в русский язык или образуясь в нем, должны приобрести родовую характеристику, которая будет проявляться только при выборе согласованных с существительным прилагательных, причастий и глаголов.
Существуют следующие закономерности выбора такими существительными родовой характеристики: род зависит либо от значения слова, либо от рода другого русского слова, которое рассматривается как синоним или как родовое наименование для данного неизменяемого слова. Для разных групп существительных ведущими являются разные критерии.
Если существительное обозначает предмет, то оно обычно приобретает характеристику среднего рода: пальто, кашне, метро. Однако женского рода авеню (так как улица), кольраби (так как это капуста), кофе — с колебанием — мужской / средний, мужской род — пенальти, евро.»
На самом деле, язык живой и что-то приживается так, что-то эдак.
Но пример с кофе, мне кажется, показательный: кофе дали несвойственный ему мужской род, а со временем слово обжилось и приобрело более точный для языка средний.
Хотя, бывает и обратное — изначально верные слова начинают использовать неправильно, не взирая при этом на все правила и признаки.
Больше по существу сказать не готов.
По ощущениям апи — оно.
У вас может быть другое мнение. Это не противозаконно и даже хорошо, что так.
…существительные с окончанием -о (-е) в именительном падеже единственного числа; десять слов на -мя…
Это имеет какое-то отношение к слову «апи», которое, ну как мне показалось, оканчивается на "-и"?
Откуда вообще сама мысль-то про средний род появилась? Из каких соображений?
Вы же сами только что написали:
…род зависит либо от значения слова, либо от рода другого русского слова, которое рассматривается как синоним или как родовое наименование для данного неизменяемого слова…
Значение: "набор готовых классов, функций и т.д. для бла-бла-бла"
Синоним: "интерфейс", "программный интерфейс" и т.п. (нерусское слово, но тем не менее уже устоявшееся в языке и с понятными «половыми признаками»)
API -> «апи» -> «интерфейс» -> мужской род.
Ну или приведите тогда уж синоним (или «родовое наименование») среднего рода для понятия «API».
…изначально верные слова начинают использовать неправильно, не взирая при этом на все правила и признаки.
Именно это вы и демонстрируете
Процитирую себя же:
Отсюда средний род.
Я вам рассказал как слова проникают в язык. Имхо, передача рода слову по смыслу очень странна, как я и написал.
Одно и то же слово можно по-разному перевести. Тогда какой род брать? Первого перевода или второго?
В общем, я считаю, что слово нужно сразу встраивать в язык и рассматривать (как уже обрусевшее) с точки зрения морфологических признаков и по аналогии с другими русскими словами определять род.
Т.е. именно не «интерфейс», не синоним, а просто «апи».
Если существительное обозначает предмет, то оно обычно приобретает характеристику среднего рода..
Отсюда средний род.
род зависит либо от значения слова, либо от рода другого русского слова
Я вам рассказал как слова проникают в язык. Имхо, передача рода слову по смыслу очень странна, как я и написал.
Одно и то же слово можно по-разному перевести. Тогда какой род брать? Первого перевода или второго?
В общем, я считаю, что слово нужно сразу встраивать в язык и рассматривать (как уже обрусевшее) с точки зрения морфологических признаков и по аналогии с другими русскими словами определять род.
Т.е. именно не «интерфейс», не синоним, а просто «апи».
Предмет? Пощупал «апи» и ощутил его тяжесть…
То есть вы создаёте новые, собственные законы морфологии? И на правила русского языка вам плевать, потому что « — Ну вот чувствую я сердцем, что оно среднего рода! Объяснить не могу, сердцем чую!»
Ещё раз вынужден процитировать вас же:
P.S. Вы ведь так и не объяснили, из каких вообще соображений возникла сама мысль про средний род…
я считаю, что слово нужно сразу встраивать в язык и рассматривать (как уже обрусевшее) с точки зрения морфологических признаков и по аналогии с другими русскими словами определять род.
То есть вы создаёте новые, собственные законы морфологии? И на правила русского языка вам плевать, потому что « — Ну вот чувствую я сердцем, что оно среднего рода! Объяснить не могу, сердцем чую!»
Ещё раз вынужден процитировать вас же:
изначально верные слова начинают использовать неправильно, не взирая при этом на все правила и признаки.
P.S. Вы ведь так и не объяснили, из каких вообще соображений возникла сама мысль про средний род…
Отличный пост!
Суть даже не в том, что «SOAP иль не SOAP, вот в чем вопрос», а в простоте и уровне абстракции.
Вы совершенно правы насчет того, что есть вещи, по поводу которых не надо заморачиваться.
Однако я не вполне согласен с такой категоричностью. SOAP (или любой его навороченный низкоуровневый заменитель) — не панацея, все зависит от конкретной реализации. На практике ничто никогда не проходит слишком гладко. В свое время мы пришли к использованию REST именно в таком контексте — нужно было что-то простое для восприятия, а воспринимается лучше то, внутреннее устройство чего понятно (речь идет, конечно, о конкретном одном уровне абстракции — том, на котором мы работаем в конкретный момент; нижележащие уровни мы здесь примем как «просто работают»).
Суть даже не в том, что «SOAP иль не SOAP, вот в чем вопрос», а в простоте и уровне абстракции.
Вы совершенно правы насчет того, что есть вещи, по поводу которых не надо заморачиваться.
Однако я не вполне согласен с такой категоричностью. SOAP (или любой его навороченный низкоуровневый заменитель) — не панацея, все зависит от конкретной реализации. На практике ничто никогда не проходит слишком гладко. В свое время мы пришли к использованию REST именно в таком контексте — нужно было что-то простое для восприятия, а воспринимается лучше то, внутреннее устройство чего понятно (речь идет, конечно, о конкретном одном уровне абстракции — том, на котором мы работаем в конкретный момент; нижележащие уровни мы здесь примем как «просто работают»).
Я не утверждаю, что SOAP всегда будет лучше. Есть ряд задач (высокая нагрузка, некритична высокая недежность, ...) где REST окажется предпочтительнее.
REST действительно проще для понимания, и если делать «в лоб», то с ним сделаешь быстрее, чем с SOAP.
А вы разрабатывали интерфейс или подключались к нему?
А вообще мне очень хочется видеть очень простые и удобные API, чтобы работать было та же просто, как с локальными либами.
REST действительно проще для понимания, и если делать «в лоб», то с ним сделаешь быстрее, чем с SOAP.
А вы разрабатывали интерфейс или подключались к нему?
А вообще мне очень хочется видеть очень простые и удобные API, чтобы работать было та же просто, как с локальными либами.
Автор, Вы — молодец. Так просто и таким легким языком описали то, о чем я боялся даже думать. Теперь не то, что бы думать, я буду использовать ЭТО.
О, «возбудил» человека на написание статьи ;)
SOAP — отлаживать сложно, не представляю как завязать OAuth с SOAP.
Велосипед — не велосипед, но думаю, что facebook и twitter придумали довольно таки не плохое API, они так и пишут, что их API использует REST-like interface.
И конечно же, спасибо за информацию!
SOAP — отлаживать сложно, не представляю как завязать OAuth с SOAP.
Велосипед — не велосипед, но думаю, что facebook и twitter придумали довольно таки не плохое API, они так и пишут, что их API использует REST-like interface.
И конечно же, спасибо за информацию!
Да! Именно вы меня сподвигли на написание. :)
Пока писал, еще раз для себя все освежил :)
Спасибо за повод!
Я работал с интересной системой (кстати, весьма нагруженной — они однозначный лидер в своей сфере). У них API разделено на 2 части: авторизация, где пользователь получает ключик, и соственно система, где он использует этот ключик.
Пока писал, еще раз для себя все освежил :)
Спасибо за повод!
Я работал с интересной системой (кстати, весьма нагруженной — они однозначный лидер в своей сфере). У них API разделено на 2 части: авторизация, где пользователь получает ключик, и соственно система, где он использует этот ключик.
Складывается ощущение что пользуется только .NET/Java и не хочет задумываться о чем-то еще. Увы, работа с SOAP, например, в C вызывает некоторые затруднения. Более того, складывается ощущение, что автор толком не понимает что такое REST. REST — это не протокол, это архитектура, следуя которой по одному и тому же адресу можно отдавать как html-страницу, так и xml, json и все что душе угодно.
Кстати, а с чего вдруг JSON стал «гиковским»?
Угу, но SOAP содержит не слабую прослойку парсера и енкодера всей это красотищи. Коие, во-первых, поедают массу ресурсов (особенно если нужно наладить локальное взаимодействие в сколько-либо реальном времени, а, во-вторых, содержат два вагона багов и уязвимостей во всех известных науке реализациях. Хотя, наверное, для взаимодействия через internet вне реального времени это всё оправдано — накладные расходы оправдываются простой распространения среди пользователей и унификацией.
Про массу ресурсов — нет ли у Вас цифр? Я, например, так и не смог выделить это поедание на фоне издержек от TCP-соединений и загрузки PHP-кода (в случае использования SOAP в PHP, естественно)… у меня есть подозрение, что экономия на парсинге XML здесь — это экономия на спичках. А уж если сравнивать SOAP с Apache Thrift (опять же, нативную реализацию SoapClient в PHP с реализацией Thrift на том же самом PHP), то SOAP оказывается почему-то удобнее и быстрее с первого взгляда.
Согласен с топиком целиком и каждой его буквой в отдельности, но, тем не менее, из предложенных вариантов больше всего мне нравится REST. Он заставляет прослеживать каждый этап работы с апи, что замедляет разработку, но зато, например, дает возможность контролировать все происходящие процессы.
Может, у меня такое мнение, потому что я не программист.
Может, у меня такое мнение, потому что я не программист.
Несколько неточностей есть. Нужно понимать разницу между форматом данных и протоколом.
XML-RPC: Пожалуй самый старый подход — данные в виде XML передаются посредством RPC (remote procedure call). Это вообще появилось с появлением XML, просто его стали использовать как формат для передаваемых параметров удалённых функций. Заметьте, что HTTP тут вообще ни при чём, это просто неточная интерпретация терминологии. И кстати, RPC как правило требует permanent connection между клиентом и сервером.
REST: Тут действительно оптимально используется протокол HTTP, со всеми глаголами. Короче, нет слов — всё очень красиво и эффективно.
SOAP: Это всего лишь стандартизированный формат передаваемых данных. Тот же XML, но с предварительно описанными в XSD типами (XSD можно вставить прямо в WSDL), сообщениями, binding-ом сообщений на методы, структурированием методов в группы и описанием собственно WebService-а. SOAP всегда ходит по какому-нибудь протоколу. У вас подразумевается HTTP, но мы однажды его пускали даже поверх Tibco, надо было :) В целом SOAP описывает то, что из себя представляет SOAP envelop и вообще, WebServices — это XML-пародия на ставшую в своё время черезчур сложной Corba. Вспомните, в корбе у нас IIOP — в вебсервисах SOAP, в корбе IDL — в вебсервисах WSDL…
В своё время я участвовал в стандартизации WS-Security в OASIS, там даже никаких токенов секурити тогда ещё не было.
А вот REST — действительно красиво и удобно.
XML-RPC: Пожалуй самый старый подход — данные в виде XML передаются посредством RPC (remote procedure call). Это вообще появилось с появлением XML, просто его стали использовать как формат для передаваемых параметров удалённых функций. Заметьте, что HTTP тут вообще ни при чём, это просто неточная интерпретация терминологии. И кстати, RPC как правило требует permanent connection между клиентом и сервером.
REST: Тут действительно оптимально используется протокол HTTP, со всеми глаголами. Короче, нет слов — всё очень красиво и эффективно.
SOAP: Это всего лишь стандартизированный формат передаваемых данных. Тот же XML, но с предварительно описанными в XSD типами (XSD можно вставить прямо в WSDL), сообщениями, binding-ом сообщений на методы, структурированием методов в группы и описанием собственно WebService-а. SOAP всегда ходит по какому-нибудь протоколу. У вас подразумевается HTTP, но мы однажды его пускали даже поверх Tibco, надо было :) В целом SOAP описывает то, что из себя представляет SOAP envelop и вообще, WebServices — это XML-пародия на ставшую в своё время черезчур сложной Corba. Вспомните, в корбе у нас IIOP — в вебсервисах SOAP, в корбе IDL — в вебсервисах WSDL…
В своё время я участвовал в стандартизации WS-Security в OASIS, там даже никаких токенов секурити тогда ещё не было.
А вот REST — действительно красиво и удобно.
Замечания приняты.
Действительно и SOAP и XML-RPC не привязаны к HTTP. Но в статье я делал упор на веб-приложения, поэтому и транспорт HTTP. Можно было рассмотреть остальное, но я бы загрузил читателей, и увел от основной темы. Поэтому оно осталось за скобками.
Да, SOAP и WS-*- это куча всего. Но у меня была цель показать, как это можно удобно использовать для API, при этом не пугать горой букв. Чтобы человек посмотрел как «дешево» с точки зрения разработки он получает отличный интерфейс. И тут же: десериализацию, контроль параметров и ответа. То есть получается, что используя более сложную технологию, с более высоким порогом входа, можно выиграть.
Если вы расскажете про WS-Security, то, думаю, многим будет интересно :)
Действительно и SOAP и XML-RPC не привязаны к HTTP. Но в статье я делал упор на веб-приложения, поэтому и транспорт HTTP. Можно было рассмотреть остальное, но я бы загрузил читателей, и увел от основной темы. Поэтому оно осталось за скобками.
Да, SOAP и WS-*- это куча всего. Но у меня была цель показать, как это можно удобно использовать для API, при этом не пугать горой букв. Чтобы человек посмотрел как «дешево» с точки зрения разработки он получает отличный интерфейс. И тут же: десериализацию, контроль параметров и ответа. То есть получается, что используя более сложную технологию, с более высоким порогом входа, можно выиграть.
Если вы расскажете про WS-Security, то, думаю, многим будет интересно :)
Ну на статью у меня времени нет, а если на пальцах то всё довольно примитивно.
В soap-конверте есть заголовок и тело, в котором собственно передаются параметры методов и результаты. Как всегда нужно обеспечить цифровую подпись конверта и иметь возможность БЫСТРО идентифицировать клиента.
Ну подпись генерируется по криптованному уже конечному контенту и вставляется в заголовок завёрнутая в специальный xml тэг.
Остаётся поместить туда же сертификат клиента чтобы сервер мог проанализировать его в первую очередь.
Ну вот и получается, что способов шифрования существует много — RSA, Kerberos итд, для каждого способа ключи и способ дешифрации немного разные. Вот стандарт WS-Security и описывает какие тэги нужно использовать в заголовке и с какими атрибутами.
С сигнатурой та же история — способов подписи несколько, нужно указать каким алгоритмом проверять.
Поначалу мы гоняли всё внутри SSL-туннеля, но он сильно просаживал CPU при наших объёмах. Да и не только у нас, поэтому и подключились к стандартизации. Дело в том, что по заголовку можно разбрасывать конверты по разным бэкендам, различая их по ключам например. Декриптовать само тело конверта на фронтенде не требуется.
Замечу, что переговоры по стандарту проходили медленно, всем хотелось сделать что-то краткое и ёмкое. Быстро стало ясно, что не получится, хотя работу над стандартизацией до конца мы довели. Потом там ещё много «WS-» стандартов было принято, но я уже не очень за этим следил.
Дело было в 2003 году, у всех тогда был пылкий интерес к вебсервисам и интернет пестрил статьями про «поворотное событие в распределённом software». На деле оказалось, что когда всё красиво смоделируешь в wsdl, то сервера умирают под нагрузкой — столько xml нужно парсить да ещё и проверять на соответствие xsd! Короче осадок остался один — это та же корба, только переписанная под xml со всеми вытекающими последствиями.
Для веба пользуйтесь REST, люди докторские не просто так получали за это (Рой Филдинг кажется). Для некоторых не очень сложных случаев вполне можно использовать и вебсервисы, хотя новое что-то я бы под них не стал сейчас создавать, их время прошло.
В soap-конверте есть заголовок и тело, в котором собственно передаются параметры методов и результаты. Как всегда нужно обеспечить цифровую подпись конверта и иметь возможность БЫСТРО идентифицировать клиента.
Ну подпись генерируется по криптованному уже конечному контенту и вставляется в заголовок завёрнутая в специальный xml тэг.
Остаётся поместить туда же сертификат клиента чтобы сервер мог проанализировать его в первую очередь.
Ну вот и получается, что способов шифрования существует много — RSA, Kerberos итд, для каждого способа ключи и способ дешифрации немного разные. Вот стандарт WS-Security и описывает какие тэги нужно использовать в заголовке и с какими атрибутами.
С сигнатурой та же история — способов подписи несколько, нужно указать каким алгоритмом проверять.
Поначалу мы гоняли всё внутри SSL-туннеля, но он сильно просаживал CPU при наших объёмах. Да и не только у нас, поэтому и подключились к стандартизации. Дело в том, что по заголовку можно разбрасывать конверты по разным бэкендам, различая их по ключам например. Декриптовать само тело конверта на фронтенде не требуется.
Замечу, что переговоры по стандарту проходили медленно, всем хотелось сделать что-то краткое и ёмкое. Быстро стало ясно, что не получится, хотя работу над стандартизацией до конца мы довели. Потом там ещё много «WS-» стандартов было принято, но я уже не очень за этим следил.
Дело было в 2003 году, у всех тогда был пылкий интерес к вебсервисам и интернет пестрил статьями про «поворотное событие в распределённом software». На деле оказалось, что когда всё красиво смоделируешь в wsdl, то сервера умирают под нагрузкой — столько xml нужно парсить да ещё и проверять на соответствие xsd! Короче осадок остался один — это та же корба, только переписанная под xml со всеми вытекающими последствиями.
Для веба пользуйтесь REST, люди докторские не просто так получали за это (Рой Филдинг кажется). Для некоторых не очень сложных случаев вполне можно использовать и вебсервисы, хотя новое что-то я бы под них не стал сейчас создавать, их время прошло.
Вот за что люблю хабр, так это за то, что как только необходимо сделать что-то чего раньше не делал, то здесь это появляется и рассказывается. Спасибо, автор.
UFO just landed and posted this here
смотрю на заголовок и жду нечто феерическое, а тут на тебе… ничегошеньки НЕ банального не нахожу…
о чем топик? просто напоминание? ну тогда да… вы справились.
о чем топик? просто напоминание? ну тогда да… вы справились.
апплодирую стоя
добавлю только пару замечаний:
1. к сожалению, сделать api на основе soap+wsdl задача весьма не тривиальная. разобраться во всех тонкостях с нуля, прямо скажем, не просто
2. единственное место, где soap+wsdl использовать не удобно (хотя, может быть, я просто что-то упустил) это javascript. для внутренних нужд оказалось проще состряпать простенький протокол на основе json
добавлю только пару замечаний:
1. к сожалению, сделать api на основе soap+wsdl задача весьма не тривиальная. разобраться во всех тонкостях с нуля, прямо скажем, не просто
2. единственное место, где soap+wsdl использовать не удобно (хотя, может быть, я просто что-то упустил) это javascript. для внутренних нужд оказалось проще состряпать простенький протокол на основе json
Тут действительно, есть над чем попотеть.
1. С другой стороны — очень удобно вашим пользователям — сгенерил либу, закинул, работаешь.
2. Да, soap слишком абстрактен для внутреннего использования. Тут и чрезмерная формализация, жесткость, оверхед.
1. С другой стороны — очень удобно вашим пользователям — сгенерил либу, закинул, работаешь.
2. Да, soap слишком абстрактен для внутреннего использования. Тут и чрезмерная формализация, жесткость, оверхед.
у нас сейчас успешно используется soap, поэтому я действительно полностью согласен — если планируется хоть сколько-нибудь сложная внешняя интеграция (скажем, более 2-3 функций), то усилия по реализации soap и wsdl полностью покрываются расслабухой на этапе непосредственно интеграции
а если вспомнить про то, что для многих языков есть не только возможность создать клиента из wsdl, но и возможность создать soap сервер и wsdl из обычных классов, функций, то получается вообще сказка :)
а если вспомнить про то, что для многих языков есть не только возможность создать клиента из wsdl, но и возможность создать soap сервер и wsdl из обычных классов, функций, то получается вообще сказка :)
Немного информации по SOAP в PHP, которая может пригодиться.
1. В PHP встроенный SoapClient и SoapServer (стандартные нативные расширения).
2. SoapClient (да и SoapServer тоже) совершенно не обязательно использовать в связке с WSDL. Можно просто объявить класс, объявить в нем методы с нужными параметрами (и возвращаемым значением произвольной структуры — хоть массива массивов массивов) и передать его в SoapServer. Точно так же, достаточно передать в SoapClient URL сервера без всякого WSDL и успешно вызвать все эти методы. Проще не придумаешь.
3. В Zend Studio for Eclipse 6.1 существует генератор WSDL-файла на основе PHP-файлов с кодом и phpdoc-комментариев (в 7.x этого средства почему-то уже нет). Работает просто великолепно! Просто пишем код, объявляем параметры функции через @param type $name и получаем готовый WSDL public-свойств класса. Причем в качестве type можно указывать как простые string, boolean и т.д., так и сложные MyClass и даже массивы объектв — MyClass[], где MyClass — это мой собственный класс (в этом случае определение этого класса попадет в WSDL-файл тоже). Я, например, никогда не рискую писать WSDL руками (именно потому, что он сложен, а утилиты — типа XMLSpy — очень кривые и сложные), но сгенерировать-то актуальную версию по классам не проблема… files.zend.com/help/Zend-Studio/generate_wsdl_files.htm и forums.zend.com/viewtopic.php?f=50&t=385 и www.zend.com/en/forums/index.php?t=msg&goto=19350&S=0c850207a026dd45faff3713958e15bf
4. SOAP в PHP — это единственный производительный (!) способ сериализовать и передать на удаленную сторону некоторую сложную структуру, состоящую из объектов, массивов, списков и т.д. так, чтобы гарантировать: там она распакуется в неизменном виде. XMLRPC-модуль в PHP на это не способен. А serialize() сериализует все подряд, включая приватные свойства, что может быть крайне неудобным. Из-за этой причины я, кстати, и выбрал протокол SOAP для своей RPC-библиотеки параллельных вызовов dklab.ru/lib/Dklab_SoapClient/ (правда, кажется, там с параллельностью что-то иногда подглючивает в самой последней версии PHP — в libcurl что-то изменили).
5. SOAP прозрачно работает с куками и сессиями. Можно, например, сделать пару вызовов $soapClient->login('user', 'pass'); $soapClient->getFriends(), и при этом на стороне сервера getFriends() будет знать о том, что до этого выполнился login() (за счет сессий или кук).
В общем, не знаю, как в других языках, а в PHP с SOAP очень комфортно работать. Даже Zend-овский генератор WSDL мне понравился больше, чем генераторы WSDL в Java (я попробовал несколько штук).
1. В PHP встроенный SoapClient и SoapServer (стандартные нативные расширения).
2. SoapClient (да и SoapServer тоже) совершенно не обязательно использовать в связке с WSDL. Можно просто объявить класс, объявить в нем методы с нужными параметрами (и возвращаемым значением произвольной структуры — хоть массива массивов массивов) и передать его в SoapServer. Точно так же, достаточно передать в SoapClient URL сервера без всякого WSDL и успешно вызвать все эти методы. Проще не придумаешь.
3. В Zend Studio for Eclipse 6.1 существует генератор WSDL-файла на основе PHP-файлов с кодом и phpdoc-комментариев (в 7.x этого средства почему-то уже нет). Работает просто великолепно! Просто пишем код, объявляем параметры функции через @param type $name и получаем готовый WSDL public-свойств класса. Причем в качестве type можно указывать как простые string, boolean и т.д., так и сложные MyClass и даже массивы объектв — MyClass[], где MyClass — это мой собственный класс (в этом случае определение этого класса попадет в WSDL-файл тоже). Я, например, никогда не рискую писать WSDL руками (именно потому, что он сложен, а утилиты — типа XMLSpy — очень кривые и сложные), но сгенерировать-то актуальную версию по классам не проблема… files.zend.com/help/Zend-Studio/generate_wsdl_files.htm и forums.zend.com/viewtopic.php?f=50&t=385 и www.zend.com/en/forums/index.php?t=msg&goto=19350&S=0c850207a026dd45faff3713958e15bf
4. SOAP в PHP — это единственный производительный (!) способ сериализовать и передать на удаленную сторону некоторую сложную структуру, состоящую из объектов, массивов, списков и т.д. так, чтобы гарантировать: там она распакуется в неизменном виде. XMLRPC-модуль в PHP на это не способен. А serialize() сериализует все подряд, включая приватные свойства, что может быть крайне неудобным. Из-за этой причины я, кстати, и выбрал протокол SOAP для своей RPC-библиотеки параллельных вызовов dklab.ru/lib/Dklab_SoapClient/ (правда, кажется, там с параллельностью что-то иногда подглючивает в самой последней версии PHP — в libcurl что-то изменили).
5. SOAP прозрачно работает с куками и сессиями. Можно, например, сделать пару вызовов $soapClient->login('user', 'pass'); $soapClient->getFriends(), и при этом на стороне сервера getFriends() будет знать о том, что до этого выполнился login() (за счет сессий или кук).
В общем, не знаю, как в других языках, а в PHP с SOAP очень комфортно работать. Даже Zend-овский генератор WSDL мне понравился больше, чем генераторы WSDL в Java (я попробовал несколько штук).
Хочу внести небольшое уточнение: аббревиатура SOAP не расшифровывается, начиная не с какой-то версии, а с актуальной на данный момент версии 1.2.
Плюс, хочу порекомендовать всем тем, кто имеет дела с SOAP-веб-сервисами, программу soapUI. Она позволяет делать с веб-сервисами практически всё: парсить WSDL, имитировать запросы и просматривать ответы, а также создавать мощные конфигурируемые mock-сервисы (очень полезно для разработки клиентов веб-сервисов).
Плюс, хочу порекомендовать всем тем, кто имеет дела с SOAP-веб-сервисами, программу soapUI. Она позволяет делать с веб-сервисами практически всё: парсить WSDL, имитировать запросы и просматривать ответы, а также создавать мощные конфигурируемые mock-сервисы (очень полезно для разработки клиентов веб-сервисов).
Классно написано, с юмором :) Прочел до конца, хоть и не программист.
почему-то я думал что конкуренция — всегда хорошо, придумывать новые вещи тоже хорошо. а по сути ведь и соапа когда-то не было, и его придумали, тоесть изобрели велосипед… сочинять и изобретать велосипеды надо, но просто при этом надо думать что делаешь, а не банально стучаться головой о стену, надеясь на то что она разверзнется
Ой, спасибо за пост.
Мой опыт программирования закончился в 92 году бэйсиком, но прочтя это, я начинаю задумываться о Пути Просветленных ))
Мой опыт программирования закончился в 92 году бэйсиком, но прочтя это, я начинаю задумываться о Пути Просветленных ))
мне по роду работы прихотидся время от времени интегрировать разные API.
SOAP он очень хорош для сферического проекта в вакууме :)
В реальной работе я предпочитаю REST.
Несколько причин:
* если SOAP работает то всё хорошо. А если нет – лучше застрелиться.
* REST достаточно прост концептуально что бы его можно было понять и собрать «на коленке».
* SOAP — приходится пользоваться код–генераторами. Что при изменении версии протокола визывает реальный гемор т.к. оригиналный сгенеренный код уже давно «причесали» и т.д.
* к REST API можно очень легко «достучаться» из javascript-а.
* Мне страшно даже подуматъ как дебаггить javascript SOAP через firebug :)
* Каждый производитель мыльной либы делает чтото слегка по своему, плюс разница версий так что часто получается несовместимость между генераторами с обоих сторон, приходится в ручную с напильником…
это толко то что сразу пришло мне в голову. причинам мылной мозговой болезни нет конца.
SOAP он очень хорош для сферического проекта в вакууме :)
В реальной работе я предпочитаю REST.
Несколько причин:
* если SOAP работает то всё хорошо. А если нет – лучше застрелиться.
* REST достаточно прост концептуально что бы его можно было понять и собрать «на коленке».
* SOAP — приходится пользоваться код–генераторами. Что при изменении версии протокола визывает реальный гемор т.к. оригиналный сгенеренный код уже давно «причесали» и т.д.
* к REST API можно очень легко «достучаться» из javascript-а.
* Мне страшно даже подуматъ как дебаггить javascript SOAP через firebug :)
* Каждый производитель мыльной либы делает чтото слегка по своему, плюс разница версий так что часто получается несовместимость между генераторами с обоих сторон, приходится в ручную с напильником…
это толко то что сразу пришло мне в голову. причинам мылной мозговой болезни нет конца.
UFO just landed and posted this here
UFO just landed and posted this here
Смена внешнего протокола — это очень серьезная вещь, ее нужно делать только в самых крайних случаях. Потому что тем самым вы можете сломать всех, кто к вам подключился по старому протоколу. В этом смысле лучше выпустить новую версию API и подключать новых пользователей на нее. А чтобы это не стало жутким гемором в поддержке, то API не должно кардинально меняться, должна быть преемственность.
Вобщем, думайте про апи как про чужую локальную либу, которую вы используете в своей программе — что будет если вдруг у нее изменятся интерфейсы? Сломает ли это вашу программу?
Но тем не менее, если надо внести изменения в интерфейс, то soap в этом поможет — т.к. вы можете сделать 2 отдельных описания, в каждое включить только те функции, которые нужно.
Вобщем, думайте про апи как про чужую локальную либу, которую вы используете в своей программе — что будет если вдруг у нее изменятся интерфейсы? Сломает ли это вашу программу?
Но тем не менее, если надо внести изменения в интерфейс, то soap в этом поможет — т.к. вы можете сделать 2 отдельных описания, в каждое включить только те функции, которые нужно.
UFO just landed and posted this here
Чувствуется, что походить по граблям стека WS* вам довелось не много. И про REST вы возможно только статьи читали.
Тем не менее — я совершенно согласен, что если задача стоит — «сделать быстро» надо делать быстро. Правильность ради красоты технического решения — декаденство в чистом виде. За него денег не взять. Если у автора быстро выходит SOAP надо пилить SOAP
Тем не менее — я совершенно согласен, что если задача стоит — «сделать быстро» надо делать быстро. Правильность ради красоты технического решения — декаденство в чистом виде. За него денег не взять. Если у автора быстро выходит SOAP надо пилить SOAP
Автору спасибо! Редко вижу слова в поддержку SOAP :)
Правда (что тут лукавить) сервисы на SOAP удобно и легко использовать, но не разрабатывать и wsdl-описывать :-)
Правда (что тут лукавить) сервисы на SOAP удобно и легко использовать, но не разрабатывать и wsdl-описывать :-)
UFO just landed and posted this here
UFO just landed and posted this here
Просто используем :)
Сервер с использованием resource_controller jamesgolick.com/2007/10/19/introducing-resource_controller-focus-on-what-makes-your-controller-special.html
# app/controllers/posts_controller.rb
class PostsController < ResourceController::Base
end
# config/routes.rb
map.resources :posts
Клиент — стандартный ActiveResource
# app/models/post.rb
class Post < ActiveResource::Base
self.site = «0.0.0.0:3000»
end
Обращаемся как к ActiveResource объекту
@user = User.find params[:id]
@user.update_attributes params[:post]
@user.save
Сервер с использованием resource_controller jamesgolick.com/2007/10/19/introducing-resource_controller-focus-on-what-makes-your-controller-special.html
# app/controllers/posts_controller.rb
class PostsController < ResourceController::Base
end
# config/routes.rb
map.resources :posts
Клиент — стандартный ActiveResource
# app/models/post.rb
class Post < ActiveResource::Base
self.site = «0.0.0.0:3000»
end
Обращаемся как к ActiveResource объекту
@user = User.find params[:id]
@user.update_attributes params[:post]
@user.save
>— Фак май мозг! — воскликнете вы и будете абсолютно правы
Именно это я про себя на английском и подумал.
Именно это я про себя на английском и подумал.
Спасибо. Очень здорово!
Желающие использовать SOAP в своих проектах могут обратить внимание на gSOAP (http://gsoap2.sourceforge.net/). Генерация WSDL, серверной и клиентской заглушки по «почти» C++ заголовочным файлам позволяют избавиться от многих головных болей. Работает эта радость практически везде, включая всяческие экзитические сочетания платформ и компилятором, короче читайте документацию. Это (чтение документации) кстати еще позволит не орать про то, что XML вообще и SOAP в частности неимоверный тормоз, а при необходимости поменять транстпорт (хоть UDP) а особо упертые смогут вообще любой серелизатор прикрутить или написать свой (да хоть ASN.1, для ценителей) правда это будет уже не совсем SOAP, но кого это волнует, если код генерируется по описанию интерфейса?
Ну и да, привет всем, кто «не осилил SOAP» (с) докладчик с HighLoad'a.
Ну и да, привет всем, кто «не осилил SOAP» (с) докладчик с HighLoad'a.
Пост осилил с интересом несмотря на объем.
По поводу сложности использования API вспомнилась мое, как возился с API Google Friend Connect.
Была у меня идея сделать так, чтобы комментарии Google Friend Connect, хранимые на серверах Google, выводились на сайт не стандартным гаджетом, а php-скриптом. Якобы это все должно было работать через OpenSocial с использованием REST; в процессе пришлось погрязнуть в какие-то ужасы, а в конце-концов разработчики (пришлось и до них добраться) признались, что через API возможно прочитать только первые 150 байт комментария.
Если честно, после этого ответа хотелось их прибить — сидишь неизвестно сколько, осваиваешь какое-то левое API, и только в последний момент выдается секрет, что толку от этого API чуть.
По поводу сложности использования API вспомнилась мое, как возился с API Google Friend Connect.
Была у меня идея сделать так, чтобы комментарии Google Friend Connect, хранимые на серверах Google, выводились на сайт не стандартным гаджетом, а php-скриптом. Якобы это все должно было работать через OpenSocial с использованием REST; в процессе пришлось погрязнуть в какие-то ужасы, а в конце-концов разработчики (пришлось и до них добраться) признались, что через API возможно прочитать только первые 150 байт комментария.
Если честно, после этого ответа хотелось их прибить — сидишь неизвестно сколько, осваиваешь какое-то левое API, и только в последний момент выдается секрет, что толку от этого API чуть.
много текста, а смысл один
— чем проще тем лучше
— чем проще тем лучше
Только при прибавлении простоты в использовании убавляется простота во внутренней реализации и работе в реальном времени.
Получается вы можете одной строкой вызвать метод на удалённой машине, но при этом генериться такая куча иксемеля, передаётся, и парсится, что простым этот способ не назовёшь )
Получается вы можете одной строкой вызвать метод на удалённой машине, но при этом генериться такая куча иксемеля, передаётся, и парсится, что простым этот способ не назовёшь )
Так вы же не сами это руками делаете?
Пусть машина об этом думает!
Пусть машина об этом думает!
С вами я не спорю )
Вашу точку зрения понял и согласен с ней.
Просто говорю, что «чем проще, тем лучше» не совсем соответствует данным подходам.
Проще в использовании, но сложнее в технологической реализации (хоть и автоматической).
Получается обратная зависимость.
Если основная задача в простейшем использовании — такой подход очевидно лучше.
Если задача в оптимизации быстродействия и ресурсоёмкости, то такое решение проигрывает более сложным в использовании, но простым в реализации.
Вот что я хотел сказать )
Вашу точку зрения понял и согласен с ней.
Просто говорю, что «чем проще, тем лучше» не совсем соответствует данным подходам.
Проще в использовании, но сложнее в технологической реализации (хоть и автоматической).
Получается обратная зависимость.
Если основная задача в простейшем использовании — такой подход очевидно лучше.
Если задача в оптимизации быстродействия и ресурсоёмкости, то такое решение проигрывает более сложным в использовании, но простым в реализации.
Вот что я хотел сказать )
Спасибо, было интересно почитать. Но вы упустили «архитектурные» плюсы WSDL.
Вкратце, это описание формата. По WSDL вы будете точно знать что вы должны отправить и что получите в ответ. Конечно увеличивается размер информации, но в этом случае вы получаете ясную картину как работать с этими «черными ящиками».
Балансировщик нагрузок, если у вас кластер одних и тех же сервисов. Ставите «форвард» сервер на вершине иерархии и он уже за вас сможет рулить нагрузкой на сервисы + он сможет узнать какие вообще сервисы существуют в вашей системе.
Это только малая часть «перелестей».
Вкратце, это описание формата. По WSDL вы будете точно знать что вы должны отправить и что получите в ответ. Конечно увеличивается размер информации, но в этом случае вы получаете ясную картину как работать с этими «черными ящиками».
Балансировщик нагрузок, если у вас кластер одних и тех же сервисов. Ставите «форвард» сервер на вершине иерархии и он уже за вас сможет рулить нагрузкой на сервисы + он сможет узнать какие вообще сервисы существуют в вашей системе.
Это только малая часть «перелестей».
Да. WSDL — это одна из самый «вкусных» вещей в SOAP.
Благодаря жесткому формальному описанию интерфейса возможна автогенерация классов для работы — поэтому и получилось так легко подключиться и работать с Аэрофлотом.
Но, что интересно, WSDL вместе с тем одна из муторных вещей, с которыми разбирается начинающий soap-ист. Доходит до анекдота — мне на форумах попадались сообщения: «Да, soap — это хорошо, но можно как-то работать без этого wsdl? А то он меня замучал». То, есть самое интересное-то и выкидывается.
Поэтому я намаренно не стал подробно его рассматривать в статье, чтобы не пугать людей :). Чтобы изучение этого стека технологий можно было начать с простого работающего примера, а не с горы непонятных спеков. Которая часто и становится непроходимым препятствием.
Благодаря жесткому формальному описанию интерфейса возможна автогенерация классов для работы — поэтому и получилось так легко подключиться и работать с Аэрофлотом.
Но, что интересно, WSDL вместе с тем одна из муторных вещей, с которыми разбирается начинающий soap-ист. Доходит до анекдота — мне на форумах попадались сообщения: «Да, soap — это хорошо, но можно как-то работать без этого wsdl? А то он меня замучал». То, есть самое интересное-то и выкидывается.
Поэтому я намаренно не стал подробно его рассматривать в статье, чтобы не пугать людей :). Чтобы изучение этого стека технологий можно было начать с простого работающего примера, а не с горы непонятных спеков. Которая часто и становится непроходимым препятствием.
Прекрасная статья! Я и не думал, что так все просто :) Спасибо
Масло — маслянное.
Читайте философию «форме и содержание» — это, да, вещь )
Читайте философию «форме и содержание» — это, да, вещь )
Поясните.
Мне казалось, что я неплохо понимаю «форму — содержание».
Мне казалось, что я неплохо понимаю «форму — содержание».
Проблема в базовом образовании — фундаментальном подходе.
Есть люди, которые малое значение придают первоисточникам, и, как следствие, часто «скачут по верхам».
Отсюда и «новые» велосипеды и другие вечные спутники прогресса.
Есть люди, которые малое значение придают первоисточникам, и, как следствие, часто «скачут по верхам».
Отсюда и «новые» велосипеды и другие вечные спутники прогресса.
Зачастую, личное мнение автора (кого и чего угодно), и борьба лидера за внедрение своих технологий — есть источник клоаки в котором крутится забавный зоопарк о котором пишет автор.
Т.е. по сути проблема в субъективном перфекционизме универсификации, с формой выражающейся во всем своем многообразии.
Т.е. по сути проблема в субъективном перфекционизме универсификации, с формой выражающейся во всем своем многообразии.
очень хочу все это осилить, но пока не хватает знаний :(
Начните постепенно. Хорошо начинать с какого-нибудь работающего примера.
Не пытайтесь сразу понять весь стек этих WS-технологий — это совершенно не нужно, и очень часто сбивает людей с толку, из-за чего они бросают. Начните использовать в каком-нибудь простом проекте «для себя», а дальше последовательно разберетесь во всем.
Не пытайтесь сразу понять весь стек этих WS-технологий — это совершенно не нужно, и очень часто сбивает людей с толку, из-за чего они бросают. Начните использовать в каком-нибудь простом проекте «для себя», а дальше последовательно разберетесь во всем.
я пытался разобраться написав приложение на FLEX, вообщем хотел повторить один сервис для нашего офиса, переписав его на flex.
Flex-ом не занимался, точно не могу сказать.
Но вот тут есть отличное видео, как работать с веб-сервисами на Flex. Получается, все очень просто, прямо как в статье выше.
Но вот тут есть отличное видео, как работать с веб-сервисами на Flex. Получается, все очень просто, прямо как в статье выше.
Тут критика принимается? Вы знаете что такое «дао»? Просто употребили его 9К раз в разных смыслах и странных формах. "… на нем я постиг дао всех веб-сервисов..." нормальный человек поймет это не так как вы думаете. Ну это все пустяки, если учитывать что было в тексте. А было в тексте интересно и познавательного много, правда есть вопрос
А какой крупный сервис предоставляет SOAP API? Для примера его нету ни у фейсбука (от этого существующего апи меня вообще коробит), ни у твиттера. Ну да ладно, но Google вообще закрыло SOAP доступ к поиску, как непреспективный, и открыло другой апи. Не наталкивает на размышления?
А какой крупный сервис предоставляет SOAP API? Для примера его нету ни у фейсбука (от этого существующего апи меня вообще коробит), ни у твиттера. Ну да ладно, но Google вообще закрыло SOAP доступ к поиску, как непреспективный, и открыло другой апи. Не наталкивает на размышления?
Критика здесь принимается. Вы правы в том, что это слово имеет массу значений. Расскажите, как его поняли вы и как должен понять «нормальный человек»?
Смотря какие крупные сервисы вы имеете ввиду. Чуть выше я говорил, что REST предпочитают социалки и массовые сервисы, SOAP — там где разговор идет про деньги: биржи, ставки, казино.
Смотря какие крупные сервисы вы имеете ввиду. Чуть выше я говорил, что REST предпочитают социалки и массовые сервисы, SOAP — там где разговор идет про деньги: биржи, ставки, казино.
Ну что вы в самом деле. Хорошого в статье намного больше чем всего остального. Спасибо.
А о дао… Дао это не такое какое хочется, это не пример, не руководство. Дао это уже существюющий принцип, закономерность. Еще у каждого свой путь. Ладно, давайте закроем тему така как убеждать я никого не хочу и толку от этого не будет никакого.
А о дао… Дао это не такое какое хочется, это не пример, не руководство. Дао это уже существюющий принцип, закономерность. Еще у каждого свой путь. Ладно, давайте закроем тему така как убеждать я никого не хочу и толку от этого не будет никакого.
Вы удивитесь, но слово «Дао» я понимаю примерно так же как Вы описали… :)
В данном случае под Дао я имел ввиду путь как смысл существования, некое предназначение (в более высоком смысле слова), предначертание веб-сервисов. Я утверждаю, что их истинный смысл не в том, чтобы просто быть, и показывать какие-то фитюльки, а быть удобным интерфейсом к сайту. То есть сами по себе они имеют очень малую ценность, но открывают доступ к функциям сайта.
Лучшее веб-апи сайта должно быть как презерватив — передавать полноту ощущений (и информации) от работы с удаленной системой, и при этом не отвлекать внимание на себя.
Да, я знаю, я выбрал довольно крепкий слог, но тем самым я хотел обратить внимание разработчиков на проектирование технических интерфейсов (веб-сервисов, апи), и донести мысль ради чего все это делается. Если кто-то написал гиганское, очень сложное апи, один учебник по работе с которым занимает 10 томов, и теперь хвалится этим, то я ему рассказываю его ошибку. Весь смысл апи — удобная работа через него. Если оно этого не дает, то это фуфло, а не апи.
Лучший веб-сервис — такой в котором слово «веб» почти не заметно. Вы его просто используете, оно просто работает.
На мой взгляд, вот это понимание и предназначение апи стало теряться среди разработчиков. Давайте сделаем «погиковее» — это так круто, Вася сделал так-то — значит и нам так надо. Да не это надо вам! Лучше просто сделайте удобно.
Центральная идея моего топика выражается в одном предложении:
А уж как и на какой технологии это сделать — не имеет значения. Возможно, я зря прямо в этом же топике привел пример и тем самым переключил внимание разработчиков из философской плоскости в практическую. Но я не люблю пустую болтовню и декларации, поэтому я показал на практике, что все может быть гораздо проще, когда задашься такой целью. И тут же дал наводку где искать.
Спасибо за Ваше внимание.
В данном случае под Дао я имел ввиду путь как смысл существования, некое предназначение (в более высоком смысле слова), предначертание веб-сервисов. Я утверждаю, что их истинный смысл не в том, чтобы просто быть, и показывать какие-то фитюльки, а быть удобным интерфейсом к сайту. То есть сами по себе они имеют очень малую ценность, но открывают доступ к функциям сайта.
Лучшее веб-апи сайта должно быть как презерватив — передавать полноту ощущений (и информации) от работы с удаленной системой, и при этом не отвлекать внимание на себя.
Да, я знаю, я выбрал довольно крепкий слог, но тем самым я хотел обратить внимание разработчиков на проектирование технических интерфейсов (веб-сервисов, апи), и донести мысль ради чего все это делается. Если кто-то написал гиганское, очень сложное апи, один учебник по работе с которым занимает 10 томов, и теперь хвалится этим, то я ему рассказываю его ошибку. Весь смысл апи — удобная работа через него. Если оно этого не дает, то это фуфло, а не апи.
Лучший веб-сервис — такой в котором слово «веб» почти не заметно. Вы его просто используете, оно просто работает.
На мой взгляд, вот это понимание и предназначение апи стало теряться среди разработчиков. Давайте сделаем «погиковее» — это так круто, Вася сделал так-то — значит и нам так надо. Да не это надо вам! Лучше просто сделайте удобно.
Центральная идея моего топика выражается в одном предложении:
Дао веб-сервиса или апи — быть простым и удобным интерфейсом.
(На этом оно начинается и на этом же заканчивается. Все, что сверх — то от лукавого.)
А уж как и на какой технологии это сделать — не имеет значения. Возможно, я зря прямо в этом же топике привел пример и тем самым переключил внимание разработчиков из философской плоскости в практическую. Но я не люблю пустую болтовню и декларации, поэтому я показал на практике, что все может быть гораздо проще, когда задашься такой целью. И тут же дал наводку где искать.
Спасибо за Ваше внимание.
просто праздник какой-то! Давно не читал ничего на хабре с таким интересом
спасибо :)
спасибо :)
Ну и где тут зарыт Дао? Простите, но нихрена нового.
Расскажите, а как Вы поняли слово Дао? И что примерно ожидали?
После введения и оглавления я ожидал магии и волшебства, которые помогут в проектировании и разработке API веб приложения, которое обезжиренное и полезно для здоровья. А а итоге, всё закончилось «ой как здорово использовать готовый soap/wsdl api».
В топике я дал несколько вещей:
— философию интерфейсов — «делайте проще и люди к вам потянутся» и не делайте просто так для галочки.
— пример технологии как можно создавать такие простые в использовании API.
Дальше думайте сами, как это реализовать :)
— философию интерфейсов — «делайте проще и люди к вам потянутся» и не делайте просто так для галочки.
— пример технологии как можно создавать такие простые в использовании API.
Дальше думайте сами, как это реализовать :)
Про понимание Дао ответил чуть выше
А мы это проходили в универе. Даже мне, на заочном, пришлось разбираться и знать.
Ваша статья помогла понять, почему же люди воротят свои системы взаимодействия, а не используют уже давно придуманные и работающие вещи.
И ещё ещё кое что про «бери и используй» прояснилось. Этого не хватает, когда переходишь с коль-нибудь низкоуровневого программирования, на использование готовых библиотек.
Спасибо.
Ваша статья помогла понять, почему же люди воротят свои системы взаимодействия, а не используют уже давно придуманные и работающие вещи.
И ещё ещё кое что про «бери и используй» прояснилось. Этого не хватает, когда переходишь с коль-нибудь низкоуровневого программирования, на использование готовых библиотек.
Спасибо.
Хорошо, когда базовые вещи проходят в универе. В противном случае, человек много времени тратит на изобретательство, это полезно поначалу для развития, но когда-то надо остановиться, и заставить себя разобраться с чужими либами.
Мне такая мысль пришла в голову — очень часто можно услышать «да я лучше свое напишу, чем стану разбираться». Это не лучшая позиция для работы в серьезном проекте — т.к. созданные велосипеды встают стеной, отгораживающей от основного направления развития отрасли. Двигаясь вбок, в какой-то момент настолько отдаляешься от отрасли, что вернуться в нее становится очень сложно. А значит не можешь использовать лучшие техники, подходы и готовые решения.
Таким образом, уйдя в добровольное гетто, обрекаешь проект на голодную смерть от недостатка ресурсов.
Мне такая мысль пришла в голову — очень часто можно услышать «да я лучше свое напишу, чем стану разбираться». Это не лучшая позиция для работы в серьезном проекте — т.к. созданные велосипеды встают стеной, отгораживающей от основного направления развития отрасли. Двигаясь вбок, в какой-то момент настолько отдаляешься от отрасли, что вернуться в нее становится очень сложно. А значит не можешь использовать лучшие техники, подходы и готовые решения.
Таким образом, уйдя в добровольное гетто, обрекаешь проект на голодную смерть от недостатка ресурсов.
SOAP сервисы чертовски сложно отлаживать при написании сервиса. Простых и быстрых утилит не существует.
Есть SoapUI, но она не простая и не удобная. Ничего лучше я не нашел.
Автор, ты очень крут.
Есть SoapUI, но она не простая и не удобная. Ничего лучше я не нашел.
Автор, ты очень крут.
asp.net web service. Разрабатывал API и писал саму бизнесс-логику.
Хотел отлаживать самоипсным клиентом, но на его написание уходила просто туча времени. Поэтому переключился на стороннюю утилиту.
Со мной можно на ты.
Хотел отлаживать самоипсным клиентом, но на его написание уходила просто туча времени. Поэтому переключился на стороннюю утилиту.
Со мной можно на ты.
Я тоже как-то закопался в одном веб-сервисе, мне в отладке помогла очень простая утилита NetTool: запросы можно посылать как с помощье ее самой, так и подключить ее как прокси. Под виндой еще есть замечательная вещь «Фигляр ПЖ» Fiddler2.
Нет желания написать статью про отладку soap под asp.net?
Нет желания написать статью про отладку soap под asp.net?
А вписывается ли в дао веб-сервисов следующая модель:
— у поставщика сервиса (прямо скажем платежный сервис
— у поставщика сервиса (прямо скажем платежный сервис
Вот досада, не ту кнопку нажал :(((
Вполне понятна ситуация, когда поставщик сервиса «Z» реализует свой SOAP-сервер, а клиентам раздает WSDL или готовую библиотеку, все работает, все довольны.
А насколько правильно, если наоборот, поставщик сервиса имеет у себя клиента, а всех кто хочет с ним интегрироваться, заставляет писать серверы? Причем, в качестве «спецификаци протокола» предоставляет примеры сообщений, в котрых без сомнения угадывается SOAP. Поможет ли добится от них предоставления WSDL?
Направьте на путь истинный :)) В какую сторону копать?
Вполне понятна ситуация, когда поставщик сервиса «Z» реализует свой SOAP-сервер, а клиентам раздает WSDL или готовую библиотеку, все работает, все довольны.
А насколько правильно, если наоборот, поставщик сервиса имеет у себя клиента, а всех кто хочет с ним интегрироваться, заставляет писать серверы? Причем, в качестве «спецификаци протокола» предоставляет примеры сообщений, в котрых без сомнения угадывается SOAP. Поможет ли добится от них предоставления WSDL?
Направьте на путь истинный :)) В какую сторону копать?
Здесь получается ситуация «наборот», такое встречается пореже.
Тем не менее, думаю, тоже можно сделать по дао.
Попробуйте у них взять WSDL-ку. Предоставят или нет — зависит от них. С другой стороны, думаю, они не зря выбрали такой формат, навеняка какой-то вариант автоматизации подключения новых партнеров предполагался. Если дадут, то вы можете автоматически сгенерить классы для своего сервиса и потом к ним подключить бизнус-логику.
Если не дадут… это хуже. Реверс-инженеринг WSDL по сообщениям, может занять некоторое время. Лично я пока не встречал каких-то автоматических тулзов.
Тем не менее, думаю, тоже можно сделать по дао.
Попробуйте у них взять WSDL-ку. Предоставят или нет — зависит от них. С другой стороны, думаю, они не зря выбрали такой формат, навеняка какой-то вариант автоматизации подключения новых партнеров предполагался. Если дадут, то вы можете автоматически сгенерить классы для своего сервиса и потом к ним подключить бизнус-логику.
Если не дадут… это хуже. Реверс-инженеринг WSDL по сообщениям, может занять некоторое время. Лично я пока не встречал каких-то автоматических тулзов.
Sign up to leave a comment.
Дао Вебсервиса. (Или да хватит же изобретать велосипеды!)