PD>С чего это авторы a.com должны были согласовывать свой интерфейс с еще не существующим c.com ? Много вас, таких, c.com найдется, на всех интерфейсов не напасешься!

Такое словосочетание как API уже отменили?

Здравствуйте, Pavel Dvorkin, Вы писали:

WF>>Не так. a.com предоставляет "машинный" (со строгим, заранее обговоренным интерфейсом) сервис getproduct. Вот мы его и вызываем.

PD>Фиг тебе, а не обговоренный интерфейс. a.com живет сам по себе и прекрасно живет. И о том, что вы собираетесь его из какого-то c.com вызывать, понятия не имеет. Все, что о нем известно, если уж быть точным — это то, что он http://a.com. Даже насчет getproduct.html я напрасно предположил. Вот если зайти на

Тогда о чем вообще речь? Ты и из своего мифического приложения из условий задачи не сможешь толком воспользоваться сервисом a.com, если единственный протокол, по которому публикуется сервис -- это HTML/JavaScript.

PD>http://a.com

PD>из броузера, то путешествую по сайту, я со временем доберусь до страницы getproduct.html, заполню там форму и получу ответ в броузере же — габариты, вес и цену.

PD>С чего это авторы a.com должны были согласовывать свой интерфейс с еще не существующим c.com ? Много вас, таких, c.com найдется, на всех интерфейсов не напасешься!

Им не надо ни с кем согласовывать. Им надо просто опубликовать свой сервис под любым удобным им "машинным" интерфейсом (SOAP, REST, JSONRPC), коли они хотят, чтобы их сервис использовался другими сервисами/приложениями.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Фиг тебе, а не обговоренный интерфейс. a.com живет сам по себе и прекрасно живет. И о том, что вы собираетесь его из какого-то c.com вызывать, понятия не имеет. Все, что о нем известно, если уж быть точным — это то, что он http://a.com. Даже насчет getproduct.html я напрасно предположил. Вот если зайти на http://a.com

Если a.com & b.com умеют отдавать только HTML, то у сервиса c.com сразу появляется огромное преимущество перед десктопным приложением — в случае изменения дизайна a.com или b.com (они же ничего не знаю о том, что их кто-то использует, верно?) все копии клиентских приложений дружно перестанут работать аж до тех пор, пока пользователь не получит новую версию. В случае с c.com большинство пользователей, скорее всего, даже не успеют заметить, что были какие-то проблемы.

Здравствуйте, Hobot Bobot, Вы писали:

HB>Если a.com & b.com умеют отдавать только HTML, то у сервиса c.com сразу появляется огромное преимущество перед десктопным приложением — в случае изменения дизайна a.com или b.com (они же ничего не знаю о том, что их кто-то использует, верно?) все копии клиентских приложений дружно перестанут работать аж до тех пор, пока пользователь не получит новую версию. В случае с c.com большинство пользователей, скорее всего, даже не успеют заметить, что были какие-то проблемы.

Правильно. Остается все же объяснить, как этот ответ получают. Никто что-то не берется.

Здравствуйте, Mamut, Вы писали:

PD>>С чего это авторы a.com должны были согласовывать свой интерфейс с еще не существующим c.com ? Много вас, таких, c.com найдется, на всех интерфейсов не напасешься!

M>Такое словосочетание как API уже отменили?

Пожалуйста, подробнее об АПИ в плане разработки a.com. Что за АПИ они должны были сделать и как он должен бы выглядеть ? Вот у RSDN есть разные линки, по которым я могу попасть на ту или иную страницу. Это и есть АПИ ?

Здравствуйте, Lloyd, Вы писали:
L>А чем так плох SOAP?
Тем, что практически полностью хоронит все преимущества HTTP.
В настоящий момент это — крайне неудобный RPC. Он создает массу проблем, и почти никаких не решает.
"Настоящий" веб-сервис — это REST, т.е. использование addressability, connectedness, и statelesness.

HB>>Если a.com & b.com умеют отдавать только HTML, то у сервиса c.com сразу появляется огромное преимущество перед десктопным приложением — в случае изменения дизайна a.com или b.com (они же ничего не знаю о том, что их кто-то использует, верно?) все копии клиентских приложений дружно перестанут работать аж до тех пор, пока пользователь не получит новую версию. В случае с c.com большинство пользователей, скорее всего, даже не успеют заметить, что были какие-то проблемы.

PD>Правильно. Остается все же объяснить, как этот ответ получают. Никто что-то не берется.

Я берусь. Только сформулируйте запрос.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Правильно. Остается все же объяснить, как этот ответ получают. Никто что-то не берется.

Обычно все-таки есть какие-то сервисы, расчитанные на интеграцию с другими приложениями. Например, тот же Google Maps имеет некий API и способ подключения к существующему приложению.

PD>>Правильно. Остается все же объяснить, как этот ответ получают. Никто что-то не берется.

dmz>Я берусь. Только сформулируйте запрос.
В смысле, вопрос.

PD>>Правильно. Остается все же объяснить, как этот ответ получают. Никто что-то не берется.

WF>Обычно все-таки есть какие-то сервисы, расчитанные на интеграцию с другими приложениями. Например, тот же Google Maps имеет некий API и способ подключения к существующему приложению.

Вообще-то, примеров — тьма. Практически любой популярный сервис имеет API. Более того, даже если он его не имеет — сделать так, что бы вашим сервисом не пользовались третьи сервисы — сложно, надо сильно ухищряться. Так что можно сказать, что практически любой сервис имеет API, даже тот, который не хочет его иметь.

Здравствуйте, WFrag, Вы писали:

WF>Тогда о чем вообще речь? Ты и из своего мифического приложения из условий задачи не сможешь толком воспользоваться сервисом a.com, если единственный протокол, по которому публикуется сервис -- это HTML/JavaScript.

Не хотел я открываться, да уж ладно.

А где это я написал в своем решении, что я вообще собираюсь использовать HTML и JavaScript ? И где в моем решении сказано, что a.com и b.com — это вообще HTTP серверы ?

Читай мое решение еще раз

http://www.rsdn.ru/forum/message/2899518.1.aspx

Автор: Pavel Dvorkin
Дата: 02.04.08

WF>Им не надо ни с кем согласовывать. Им надо просто опубликовать свой сервис под любым удобным им "машинным" интерфейсом (SOAP, REST, JSONRPC), коли они хотят, чтобы их сервис использовался другими сервисами/приложениями.

OK, принимается. Это уже ближе к делу. В таком случае, поправь мое решение (поскольку Sinclair что-то молчит) и выдай от своего имени. Я не буду ничего говорить, пока не увижу утвержденного решения. Иначе дискуссия будет бесконечной.

Здравствуйте, Pavel Dvorkin, Вы писали:


PD>Для решения этой задачи мы создаем промежуточный web-сервис c.com, на котором функционирует специальный web-сервис.
Мы создаем промежуточное веб-приложение.
Веб-приложение состоит из серверной части (код на стороне HTTP сервера), и клиентской части — некоего HTML/CSS/Javascript.
В нашем случае хватает банального HTML+CSS, JavaScript не нужен.

PD>Пользователь из броузера делает запрос к c.com, передавая в запросе адрес назначения и имя продукта.
Ну, давай подробнее.
0. Пользователь из браузера делает запрос к сайту c.com:
http://www.c.com/
1. Сервер в ответ отдает ему страницу, которая рассказывает о том, куда он попал, и всё такое прочее, что выходит из отдела маркетинга. Существенным является то, что с этой страницы есть ссылка на приложение. В нашем случае точкой входа в приложение является вот такой URL:
http://www.c.com/estimateDeliveryPrice.aspx
2. Теперь сервер отдает клиентскую часть приложения. Это банальная HTML форма. Принципиальное устройство формы таково:

<form>
 <label for="itemName">Введите название товара:</label><br>
 <input id="itemName" name="itemName" type=text size=50><br>
 <label for="deliveryAddress">Введите название товара:</label><br>
 <textarea id=deliveryAddress name=deliveryAddress rows=5 cols=80>
 </textarea>
 <input type=submit value="поехали">
</form>

3. Получив эту форму, агент(браузер) показывает ее пользователю. Пользователь заполняет данные и нажимает Submit.
4. В соответствии со спецификацией HTML и HTTP, браузер выполняет переход на адрес
http://www.c.com/estimateDeliveryPrice.aspx?itemName=слон&deliveryAddress=Омск
Вот теперь
5. Получив этот запрос, сервис c.com создает web-клиента и делает запрос к серверу a.com.
Этот момент не вполне понятен. Поскольку ты ничего не сказал про то, как устроен сервер a.com, мне трудно делать какие-либо предположения о том, как именно будет сформирован запрос. Получать форму с a.com большого смысла нет — если поменяется обработчик формы, то скорее всего изменится и сама форма.
Поэтому скорее всего серверная часть приложения c.com отправит HTTP POST-запрос на известный ей адрес где-то на сервере a.com.
6. Сервер a.com принимает этот запрос и формирует ответ.
7. Сервис c.com получает этот ответ, выбирает из него вес, габариты и цену продукта. Тут могут быть особенности связанные с форматом представления, выбранным a.com
8. После этого c.com отсылает по протоколу HTTP новый запрос к b.com, передавая данные, полученные от пользователя и a.com
9. Получив ответ, он извлекает из него стоимость пересылки, добавляет к стоимости продукта, полученной от a.com и отсылает пользователю форму с результатом.(Обработка ошибок пропущена)
Вот, это и есть правильное решение поставленной задачи. С точностью до обработки ошибок, кэширования, и деталей протоколов взаимодействия с a.com и b.com.

PD>Давай договоримся вот о чем. Если ты с чем-то не согласен — возьми этот текст и отредактируй. Не надо мне 400 и 404, не вдавайся в такие детали, а просто отредактируй то, что я написал. И не критикуй. Не согласен — исправь. И подпиши — за сим, я , Sinclair, утверждаю, что это и есть правильно организованное web-решение поставленной задачи.

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Отличия сервера от клиента в студию.
Клиент — активная сторона взаимодействия, сервер — пассивная.
Термины "клиент" и "сервер" могут применяться только в контексте конкретного диалога.
Например, когда я отправляю почту по SMTP, мой outgoing MTA — сервер, а outlook — клиент.
Когда тот же самый MTA отправляет почту на responsible MTA адресата, он является клиентом.
Когда responsible MTA возвращает моему MTA delivery status notification, он становится клиентом, а мой MTA — опять сервером.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Не хотел я открываться, да уж ладно.

PD>А где это я написал в своем решении, что я вообще собираюсь использовать HTML и JavaScript ? И где в моем решении сказано, что a.com и b.com — это вообще HTTP серверы ?

Вот и отлично. Пусть это какие-то сервисы, с известными протоколами.

PD>OK, принимается. Это уже ближе к делу. В таком случае, поправь мое решение (поскольку Sinclair что-то молчит) и выдай от своего имени. Я не буду ничего говорить, пока не увижу утвержденного решения. Иначе дискуссия будет бесконечной.

Примерно так:

Пользователь открывает приложение на c.com, выдается форма, в которой запрашивается название продукта и адрес получателя. После нажатия Submit, серверная сторона приложения берет название и отправляет серверу a.com. Получив ответ от него, оно берет полученные данные, добавляет к ним адрес получателя и шлет серверу b.com. Полученный от него ответ возвращается клиентской части веб-приложения (например, как новая страница).

Я не пойму, в чем подвох-то? o_0

Здравствуйте, Pavel Dvorkin, Вы писали:

HB>>Если a.com & b.com умеют отдавать только HTML, то у сервиса c.com сразу появляется огромное преимущество перед десктопным приложением — в случае изменения дизайна a.com или b.com (они же ничего не знаю о том, что их кто-то использует, верно?) все копии клиентских приложений дружно перестанут работать аж до тех пор, пока пользователь не получит новую версию. В случае с c.com большинство пользователей, скорее всего, даже не успеют заметить, что были какие-то проблемы.

PD>Правильно. Остается все же объяснить, как этот ответ получают. Никто что-то не берется.

Какой ответ?
Я вообще не могу понять в чем вы видите разницу между обращением к сервисам a.com и b.com из клиентской программы или из кода, выполняющегося на третьем сервере. Ну нет этой разницы — независимо от того, какой протокол поддерживают a.com и b.com.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А где это я написал в своем решении, что я вообще собираюсь использовать HTML и JavaScript ? И где в моем решении сказано, что a.com и b.com — это вообще HTTP серверы ?
Это как раз совершенно неважно, чего именно они серверы.
Серверы — значит умеют отвечать по некоторому известному протоколу.
Если не умеют — значит они не существуют в природе, т.е. это не серверы.

M>>Такое словосочетание как API уже отменили?

PD>Пожалуйста, подробнее об АПИ в плане разработки a.com. Что за АПИ они должны были сделать и как он должен бы выглядеть ? Вот у RSDN есть разные линки, по которым я могу попасть на ту или иную страницу. Это и есть АПИ ?

ЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫ

RSDN@Home умеет вытягивать данные с RSDN.ru? Умеет. Почему сервер некоег сервиса не может вытягивать данные с RSDN.ru абсолютно таким же образом?

Здравствуйте, Sinclair, Вы писали:

PD>>Пользователь из броузера делает запрос к c.com, передавая в запросе адрес назначения и имя продукта.
S>Ну, давай подробнее.
S>0. Пользователь из браузера делает запрос к сайту c.com:
S>http://www.c.com/

Вот это ясно.

S>1. Сервер в ответ отдает ему страницу, которая рассказывает о том, куда он попал, и всё такое прочее, что выходит из отдела маркетинга. Существенным является то, что с этой страницы есть ссылка на приложение.


Я правильно понял, что предыдущее решение, когда делается запрос от клиента к c.com и все остальное вплоть до получения окончательного ответа, происходит без участия клиента ? Вроде так было. Или нет ? Как я понял — уже нет. Два этапа — просто запрос к c.com, получение страницы с "о том, куда он попал, и всё такое прочее" и ссылкой на приложение ? Ладно.

>В нашем случае точкой входа в приложение является вот такой URL:
S>http://www.c.com/estimateDeliveryPrice.aspx

Допустим.

S>2. Теперь сервер отдает клиентскую часть приложения. Это банальная HTML форма. Принципиальное устройство формы таково:

<skipped>

S>3. Получив эту форму, агент(браузер) показывает ее пользователю. Пользователь заполняет данные и нажимает Submit.
S>4. В соответствии со спецификацией HTML и HTTP, браузер выполняет переход на адрес
S>http://www.c.com/estimateDeliveryPrice.aspx?itemName=слон&deliveryAddress=Омск

Жду слона с нетерпением. Розовый чтоб был!

S>Вот теперь
S>5. Получив этот запрос, сервис c.com создает web-клиента и делает запрос к серверу a.com.
S>Этот момент не вполне понятен. Поскольку ты ничего не сказал про то, как устроен сервер a.com, мне трудно делать какие-либо предположения о том, как именно будет сформирован запрос. Получать форму с a.com большого смысла нет — если поменяется обработчик формы, то скорее всего изменится и сама форма.

Прекрасно. Я действительно ничего не сказал. АПИ, который тут требуют другие, не определен. А посему куда именно твой web-клиент обратится, я тоже не знаю. Но и определять я его не буду — не мое же решение, а твое. Определи как хочешь и расскажи, как. Назначаю тебя на некоторое время разработчиком a.com. Только имей в виду, что c.com будет делаться через 5 лет, а может, и вообще не будет. Ты о нем ничего не знаешь.

S>Поэтому скорее всего серверная часть приложения c.com отправит HTTP POST-запрос на известный ей адрес где-то на сервере a.com.

Пусть так.

S>6. Сервер a.com принимает этот запрос и формирует ответ.

Подробнее, пожалуйста ? Шлет в ответ страницу ?

S>7. Сервис c.com получает этот ответ, выбирает из него вес, габариты и цену продукта. Тут могут быть особенности связанные с форматом представления, выбранным a.com

Во-во. Не уходи от этого ответа. Я ведь тебя 5 лет назад назначал разработчиком a.com, а сейчас я разрабатываю c.com, так что будь добр ответь мне, как там все это вытащить. Кстати, твоя страница еще картинку с этим продуктом шлет и прочее. Мне это без надобности, расскажи, как отфильтровать.

S>8. После этого c.com отсылает по протоколу HTTP новый запрос к b.com, передавая данные, полученные от пользователя и a.com

Ну это ясно.

S>9. Получив ответ, он извлекает из него стоимость пересылки, добавляет к стоимости продукта, полученной от a.com и отсылает пользователю форму с результатом.(Обработка ошибок пропущена)

Здесь тоже ясно. Кроме того, как вытащить из страницы от b.com стоимость пересылки. Но это та же проблема. Правда, разработчиком b.com ты не был, так что даже рассказать ничего не можешь...

Просьба — еще одну итерацию. Только опять полный текст. Не надо формы приводить, несущественно это. Словами опиши. Но полное решение. И подпишись

Здравствуйте, WFrag, Вы писали:

WF>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Не хотел я открываться, да уж ладно.

PD>>А где это я написал в своем решении, что я вообще собираюсь использовать HTML и JavaScript ? И где в моем решении сказано, что a.com и b.com — это вообще HTTP серверы ?

WF>Вот и отлично. Пусть это какие-то сервисы, с известными протоколами.

Теплее


WF>Пользователь открывает приложение на c.com, выдается форма, в которой запрашивается название продукта и адрес получателя. После нажатия Submit, серверная сторона приложения берет название и отправляет серверу a.com. Получив ответ от него, оно берет полученные данные, добавляет к ним адрес получателя и шлет серверу b.com. Полученный от него ответ возвращается клиентской части веб-приложения (например, как новая страница).

Прекрасно. То есть c.com общается с a.com и b.com не посылкой HTTP запросов GET и POST, а с помощью некоторого протокола типа SOAP или что-то еще ? Правильно ?

А подвоха нет никакого.

Ответов сегодня от меня больше не будет. До завтра!