Павел, а можно такое же полное решение для аналогичного клиентского приложения? С подписью и печатью.
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
PD>Прекрасно. Я действительно ничего не сказал. АПИ, который тут требуют другие, не определен. А посему куда именно твой web-клиент обратится, я тоже не знаю. Но и определять я его не буду — не мое же решение, а твое. Определи как хочешь и расскажи, как. Назначаю тебя на некоторое время разработчиком a.com. Только имей в виду, что c.com будет делаться через 5 лет, а может, и вообще не будет. Ты о нем ничего не знаешь.
Сервис c.com создается не в вакууме, и сервисы a.com и b.com тоже существуют не в вакууме. Самый крайний случай — это выдирание и парсинг HTML'я (web-scraping), но это действительно самый крайний случай.
А так люди веб-сервисы и микроформаты исключительно для десктоп-приложений выдумали, ага
PD>Прекрасно. То есть c.com общается с a.com и b.com не посылкой HTTP запросов GET и POST, а с помощью некоторого протокола типа SOAP или что-то еще ? Правильно ?
Это зависит от сервисов. Google APIs вполне себе поверх REST живут. Предлагаю домашнее задание — изучить, что такое SOAP, и как с помощью него делаются запросы (hint: c помощью GET/POST)
Здравствуйте, Sinclair, Вы писали:
L>>А чем так плох SOAP? S>Тем, что практически полностью хоронит все преимущества HTTP. S>В настоящий момент это — крайне неудобный RPC. Он создает массу проблем, и почти никаких не решает. S>"Настоящий" веб-сервис — это REST, т.е. использование addressability, connectedness, и statelesness.
А как REST решает поддержку транзакционности? Есть ли стандартизированные и унифицированные способы аутентификации, авторизации, возврата информации об ошибке?
C>А как REST решает поддержку транзакционности? Есть ли стандартизированные и унифицированные способы аутентификации, авторизации, возврата информации об ошибке?
C>>А как REST решает поддержку транзакционности? Есть ли стандартизированные и унифицированные способы аутентификации, авторизации, возврата информации об ошибке?
dmz>Никак не решает. А что — SOAP как-то решает?
Кроме того, SOAP не привязано к HTTP/HTTPS в отличии от REST. Главный смысл SOAP и Web Services в стандартизации общения между сервисами + наличие инструментов, которые позволяют автоматизировать часть работы.
Конечно всегда можно создать REST решение, превосходящее во всех отношениях SOAP и "WS-*", вопрос лишь во времени разработки и удобства использования.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Прекрасно. То есть c.com общается с a.com и b.com не посылкой HTTP запросов GET и POST, а с помощью некоторого протокола типа SOAP или что-то еще ? Правильно ?
Под SOAP имелся ввиду вариант SOAP over HTTP, как самый распространенный вариант. Дальше продолжать?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Подробнее, пожалуйста. Сервер — каким именно образом он эти запросы делать будет ? Он умеет сам запросы от броузеров принимать (с помощью web-сервера), а вот web-клиентом он не является.
Мда... На этом сообщении, пожалуй, остановлюсь. А то ведь собрался всю тему читать
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Пусть так.
S>>6. Сервер a.com принимает этот запрос и формирует ответ.
PD>Подробнее, пожалуйста ? Шлет в ответ страницу ?
Как правило — да. S>>7. Сервис c.com получает этот ответ, выбирает из него вес, габариты и цену продукта. Тут могут быть особенности связанные с форматом представления, выбранным a.com
PD>Во-во. Не уходи от этого ответа. Я ведь тебя 5 лет назад назначал разработчиком a.com, а сейчас я разрабатываю c.com, так что будь добр ответь мне, как там все это вытащить.
Очень просто. Я использую sgmlReader для того, чтобы превратить выход сервиса a.com в DOM документ. Затем над полученным DOM документом я выполняю несколько XPath запросов, чтобы вытащить нужные мне данные. Либо, если это оказывается более удобным, я использую несложные Regex выражения для той же цели.
PD>Кстати, твоя страница еще картинку с этим продуктом шлет и прочее. Мне это без надобности, расскажи, как отфильтровать.
Из упоминания картинки я делаю вывод, что HTML ты тоже не знаешь. Дело в том, что "картинку" страница не отсылает. Картинка в ней присутстует в виде ссылки. Веб браузер ее автоматически вытаскивает, а мой сервис c.com этого делать не будет. Поэтому никакого "отфильтровать" не надо.
S>>8. После этого c.com отсылает по протоколу HTTP новый запрос к b.com, передавая данные, полученные от пользователя и a.com
PD>Ну это ясно.
S>>9. Получив ответ, он извлекает из него стоимость пересылки, добавляет к стоимости продукта, полученной от a.com и отсылает пользователю форму с результатом.(Обработка ошибок пропущена)
PD>Здесь тоже ясно. Кроме того, как вытащить из страницы от b.com стоимость пересылки. Но это та же проблема. Правда, разработчиком b.com ты не был, так что даже рассказать ничего не можешь...
Применю ту же технику, что и для сервиса a.com.
Оба варианта приведены для случая, когда разработчики a и b не осознавали популярности своих услуг, и делали исключительно человеко-ориентированные приложения. В реальной жизни у обоих сервисов есть один или несколько HTTP-based API.
Если они разработаны в конце девяностых, то это будет банальный HTTP POST, где и запрос и ответ представлены в виде пар ключ=значение. Такой протокол поддерживает большинство платежных систем — по историческим причинам.
Если разрабатывались в 2000-2003, то скорее всего будет применено что-то типа XML-RPC. В 2003-2006 был в моде SOAP. В 2007-2008 начинается восход архитектуры REST и микроформатов; а также всякая экзотика вроде JavaScript API. Эти API обычно документированы, что позволяет мне легко интегрировать их услуги в свое приложение.
PD>Просьба — еще одну итерацию. Только опять полный текст. Не надо формы приводить, несущественно это. Словами опиши. Но полное решение. И подпишись
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
M>>Веб приложение — это не просто морда на HTML. Это морда на ХТМЛ плюс сервер. Сервер также ничем не ограничен. Он также может слать запросы хоть в сотню мест одновременно PD>Может. Только вот при этом ему придется отнюдь не серверными делами заниматься, и изображать из себя то web-client, то ftp-client, то еще что-нибудь. Он уже, по сути не сервер, а нечто общее будет.
И правильно. Поскольку это есть узел распределённой информационной системы. Что он делает, по каким протоколам с кем-то ещё связывается — вопрос очень сильно отдельный. "Сервер", это же не награда за доблесть, а просто роль (как, кстати, это правильно отметил Sinclair) в определённых взаимодействиях. Скажу больше, в рамках одной транзакции узлы А и Б могут резко поменяться ролями и не один раз. Соответственно, на одном физическом компьютере (или кластере) могут исполняться программы, выполняющие как роль серверов (предоставление сервисов), так и роль клиентов (запрос данных, использование других сервисов). Дальше банальная формальная логика: некий компьютер может выполнять преимущественно серверные функции, и потому его можно обобщённо назвать "сервером". Но из того, что его назвали "сервером" ещё не следует, что этот компьютер выполняет только серверные функции.
PD>>>А ты сумел это решение в рамках AJAX реализовать. Я ведь и писал, что AJAX — это некая попытка вернуться к здравому смыслу. Но усложнить задачу — и тебе понадобятся либо еще d.com, e.com..., либо такой уж C.com, который будет все делать. M>>И? Сервер c.com, который будет делать запросы ко всем этим сторонним сервисам куда делся? Никуда. PD>Да, только функционал его резко возрастает и становится не серверным.
И славно! Как минимум, пользователь избавлен от необходимости апдейтить своё приложение, если a.com и b.com надумали поменять API, добавить/убрать услуги и т.п. Всем этим централизованно занимается обслуга c.com.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Прекрасно. То есть c.com общается с a.com и b.com не посылкой HTTP запросов GET и POST, а с помощью некоторого протокола типа SOAP или что-то еще ? Правильно ?
c.com — есть веб-приложение с точки зрения конечного пользователя. Потому что оно предлагает ему веб-интерфейс и расположено в веб, а не на его десктопе. И единственным условием его использования для конечного пользователя является наличие у него совместимого браузера. Все. Это и определяет статус "веб-приложение" (для конечного пользователя)
Каким образом и какими протоколами c.com общается с a.com и b.com значение не имеет. Хоть посредством божественной благодати или силы джедаев. Это все проблемы разработчиков, пользователя они не интересуют и на статус конечного приложения они не влияют.
Ну и как уже сказано -если a.com и b.com — это именно сервисы, а не конечные приложения, то они должны предоставлять какое-то АПИ для использования их функционала другим ПО (для веб-сервисов это логичнее всего что-то поверх http/https, но в принципе — не обязательно). Если такого функционала нет — то это просто клиентские приложения, но не сервисы. И строить приложения поверх них — плохая идея. Это все равно что делать, ну например, десктоп приложение, которое бы из ICQ брало приходящий текст и отображало его в Acrobat Reader. И потом удивляться, что это, блин, неудобно!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Решение с клиентом
PD>Клиент выдает на экран форму, в которой запрашивается название продукта и адрес получателя. Эта форма не получена ни с a.com, ни c b.com, а просто принадлежит клиентному приложению. После нажатия Submit клиентное приложение берет название и отправляет серверу a.com. Получив ответ от него, оно берет полученные данные, добавляет к ним адрес получателя и шлет серверу b.com. Полученный от него ответ возвращается пользователю.
В качестве критики воспользуюсь благородным древним слогом: "Галимый отстой! Это же 2-уровневая система! Да ещё и с толстым клиентом! А если сервер поменяется? Что? Всех клиентов обновлять? Щаззз, разбежался! Маздай!!! Эн-тайер рулит форевер!"
По существу, от 2-уровневых приложений (тем паче, с толстыми клиентами) стали отказываться как раз из-за проблем с деплойментом обновлений. Тонкие клиенты на базе JS и иже с ними начисто лишены этих заморочек (Ctrl-F5 не считается). Другое дело, что изобразительные возможности HTML — ну да, это печально, конечно.
PD>Ваше решение ?
PD>Категорическое требование — сервер a.com решительно не хочет ничего знать о почтовых делах и даже о существовании b.com, а b.com — не интересуется продуктами и не знает о наличии a.com.
Нужно оценить изменчивость требований и колебания интерфейсов a.com и b.com. Если они меняются часто, то есть вероятность, что клиентские приложения очень быстро окажутся неработоспособными, либо нужно сразу вводить возможность автообновления приложения.
Но если у нас есть возможность поднять собственный общедоступный узел, то всю логику обсчёта и сбора информации мы положим на этот узел, а клиенты будут обращаться на узел сей с запросами типа "название товара, адрес доставки -> цена доставки".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Curufinwe, Вы писали:
C>Здравствуйте, Sinclair, Вы писали:
L>>>А чем так плох SOAP? S>>Тем, что практически полностью хоронит все преимущества HTTP. S>>В настоящий момент это — крайне неудобный RPC. Он создает массу проблем, и почти никаких не решает. S>>"Настоящий" веб-сервис — это REST, т.е. использование addressability, connectedness, и statelesness.
C>А как REST решает поддержку транзакционности?
Никак. С точки зрения REST, 1 транзакция == 1 HTTP Request.
Чтобы обойти это ограничение, вводится дополнительный ресурс "транзакция", который за несколько запросов подготавливается, и затем одним запросом выполняется коммит. C>Есть ли стандартизированные и унифицированные способы аутентификации, авторизации, возврата информации об ошибке?
Аутентификации — есть. Авторизации — нету, поскольку она за пределами протокола. Возврат информации об ошибке значительно более развит, чем в SOAP. C>P.S. а что подразумевается под connectedness?
Возможность ссылаться из одного документа в другой.
REST веб-сервис позволяет до любого ресурса в рамках объектной дойти по ссылкам, начиная от service entry point.
Грубо говоря, в SOAP ты должен догадаться, что можно вызвать метод GetCustomers(), а потом передать один из ID полученных кастомеров в совершенно отдельный метод GetCustomerOrders(customerID).
А в REST ты получаешь, допустим, feed кастомеров, где каждая entry указывает на "страничку покупателя". Со странички покупателя на feed с его заказами ведет ссылка.
В итоге у тебя 2 способа получить доступ к некоторому ресурсу:
1. Сконструировать URL по заранее известным правилам
2. Проследовать до нужного ресурса, выбирая на каждом шагу нужную ссылку по определенным критериям
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mamut, Вы писали:
M>>>Такое словосочетание как API уже отменили?
PD>>Пожалуйста, подробнее об АПИ в плане разработки a.com. Что за АПИ они должны были сделать и как он должен бы выглядеть ? Вот у RSDN есть разные линки, по которым я могу попасть на ту или иную страницу. Это и есть АПИ ?
M>ЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫ
M>RSDN@Home умеет вытягивать данные с RSDN.ru? Умеет. Почему сервер некоег сервиса не может вытягивать данные с RSDN.ru абсолютно таким же образом?
Здравствуйте, Mamut, Вы писали:
PD>>Прекрасно. То есть c.com общается с a.com и b.com не посылкой HTTP запросов GET и POST, а с помощью некоторого протокола типа SOAP или что-то еще ? Правильно ?
M>Это зависит от сервисов. Google APIs вполне себе поверх REST живут. Предлагаю домашнее задание — изучить, что такое SOAP, и как с помощью него делаются запросы (hint: c помощью GET/POST)
Спасибо. Упражнение было выполнено примерно год назад, когда я программировал web-service
Hint : я же написал в письме к Sinclair, что я занимаюсь провокаторской деятельностью
Итак, в качестве одного из вариантов предлагается : c.com делает запросы к a.com (b.com) с помощью SOAP, используя при этом HTPP GET/POST. Правильно ? При этом a.com как-то определил свой интерфейс (SOAP), и c.com его знает, а поэтому может обратиться , используя этот интерфейс. Впрочем, можно и не SOAP, а что-то иное.
Здравствуйте, Mamut, Вы писали:
M>>(hint: c помощью GET/POST) M>Имел в виду с их помощью в том числе. HTTP ничем не отличется от других протоколов взаимодействия
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Прекрасно. То есть c.com общается с a.com и b.com не посылкой HTTP запросов GET и POST, а с помощью некоторого протокола типа SOAP или что-то еще ? Правильно ?
WF>Под SOAP имелся ввиду вариант SOAP over HTTP, как самый распространенный вариант. Дальше продолжать?
Нет. Блестяще. И ты, и Mamut пришли к одному и тому же и объяснили мне, неграмотному, как это должно выглядеть
