SOA vs REST - Архитектура программного обеспечения

Здравствуйте, hattab, Вы писали:
H>Зачем же, просто не нужно молиться на эту священную корову.
Нужно. Нужно, потому что это единственный способ скомпенсировать распределённую природу приложения.
Вы понимаете, что как вы ни оптимизируйте свой RPC сервис, а раундтрип к нему всё равно занимает столько, сколько занимает?
Кэш позволяет снизить латентность вообще до нулевых цифр. Впрочем, я понимаю, что вам наплевать — вы же выбрали "стандартный" XML-RPC, который сам по себе вчетверо избыточнее даже тупого SOAP, который неспособен сэкономить походы на сервер.
А тем, кому не наплевать, желательно понимать, как достигается хорошая производительность.

H>Ну, во первых, у нашего далеко не одна. Но, конечно, с количеством инсталлей сквида не сравнить. Вот только проксями, в нашем не идеальном мире живых людей, пользуются очень и очень разными, а не из топ 3.
Да ладно. Ну расскажите мне, каковы шансы встретить экзотику, при наличии полностью бесплатных lighttpd и nginx.

H>При том, что в codebase активикса указывается ссылка на *.inf, а уже в нем прописывается версия файла и прочие детали. Ну а хидеры... Да не вспомню я сейчас, что там в 2001 году было. Помню, хостилось оно все под IIS, и сношались мы с этой радостью очень долго. Кстати, потом в инете, я где-то находил подтверждение этой проблемы.
Ну да, проблемы 12летней давности, конечно же, актуальны при принятии архитектурных решений.
У меня в то время тоже были постоянные проблемы с кэшами. В основном потому, что сайтом ietf.org я тогда не владел, и протокол HTTP понимал очень приблизительно. Тем более, что средств отладки типа fiddlertool.com тогда ещё не было, и мы реально гадали о состоянии кэша по визуальному поведению браузера (незамутнённые идиоты, да).

H>Откуда вдруг взялась невозможность потребления сервиса из тонкого клиента?
Не невозможность потребления сервиса, а невозможность пользования вашим велосипедным кэшированием.
H>Не нужно выдумывать. Я уже сказал, что для XML-RPC есть JS-реализации. Просто мы таких клиентов не делаем. И, кстати, WinInet'ом не пользуемся тоже.
Да я прекрасно понял уже ваше стремление к пессимизации приложений.

H>У меня есть опыт разработки веб-сервера с нуля, т.е. с уровня сокетов и пула потоков. Прокси для XML-RPC делается на его основе элементарно

То есть вот реально вы думаете, что авторы тупых HTTP-проксей неспособны сделать безглючную реализацию, а ваш умный прокси для XML-RPC легко сделать безошибочным? А, ну удачи.

H>У нас такие приложения, что кэширование практически неприменимо

Но это не отрицает возможности его реализации в RPC.
Все так говорят. В прошлый раз, когда мне пытались привести пример приложения, где кэширование неприменимо, получилось смешно.
У вас не кэширование неприменимо, у вас потребности в высокой производительности нет.

H>Вот так всегда, как только речь заходит о конкретике, сторонники REST вспоминают о каком-то одном, конкретном, REST-фреймвоке

А что делать юзерам проповедующим другой конкретный REST-фреймвок для повзаимодействовать с вашим сервисом? Правильно, выкинуть свой конкретный REST-фреймвок и принять ваше вИдение. Нужно ли говорить о том, что в протоколах решающих эту задачу на уровне именно протокола, таких проблем нет и двое человек говорящих об обработке ошибок или формате сериализации понимают, что говорят об одном и том же. И таки да, их никто не обязывает юзать фреймвок, можно так же тупо ручками.
Знаете, если этот "один и тот же" формат — это XML-RPC, то я лучше пешком постою.

H>На размер URI разумеется.
Ссылочку на ограничение размера URI в дефолтных реализациях не затруднит?
H>Я тебе уже как-то показывал, насколько хорошо решает сжатие, как раз таки на примере с base64.
На примере с реальными данными сжатие работает ещё лучше.

H>Это заблуждение. Клиент XML-RPC или JSON-RPC сервиса получив вместо 200 OK, 301 или 307 преспокойно сменит endpoint на указанный в location. Никакой драмы и трагедии нет.
Сначала нужно чтобы кто-то отдал этот 301 или 307. Я же говорю — вам нужен Load Balancer, а он не бесплатен.

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

S> H>Зачем же, просто не нужно молиться на эту священную корову.

S> Нужно. Нужно, потому что это единственный способ скомпенсировать распределённую природу приложения.
S> Вы понимаете, что как вы ни оптимизируйте свой RPC сервис, а раундтрип к нему всё равно занимает столько, сколько занимает?
S> Кэш позволяет снизить латентность вообще до нулевых цифр. Впрочем, я понимаю, что вам наплевать — вы же выбрали "стандартный" XML-RPC, который сам по себе вчетверо избыточнее даже тупого SOAP, который неспособен сэкономить походы на сервер.
S> А тем, кому не наплевать, желательно понимать, как достигается хорошая производительность.

Когда ты говоришь о нулевой латентности, ты имеешь ввиду кэш основанный на временнЫх метках. Но в случае с кэшированием ориентированным на ETag (те случаи, когда актуализация данных на клиенте критична) от полного раундтрипа ты не избавлен. Ну и о якобы избыточности XML-RPC. Вот живой пример использования гуглового сервиса:

SOAP (582 байта, без индентинга 549):

<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
  <SOAP-ENV:Body>
    <ns1:doSpellingSuggestion xmlns:ns1="urn:GoogleSearch"
        SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
      <key xsi:type="xsd:string">00000000000000000000000000000000</key>
      <phrase xsi:type="xsd:string">britney speers</phrase>
    </ns1:doSpellingSuggestion>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

А так выглядел бы вариант для XML-RPC (294 байт, без индентинга 260):

<?xml version="1.0" encoding="utf-8"?>
<methodCall>
  <methodName>google.doSpellingSuggestion</methodName>
  <params>
    <param>
      <value>00000000000000000000000000000000</value>
    </param>
    <param>
      <value>britney speers</value>
    </param>
  </params>
</methodCall>

или еще XML-RPC с именованными параметрами (492 байта, без индентинга 362):

<?xml version="1.0" encoding="utf-8"?>
<methodCall>
  <methodName>google.doSpellingSuggestion</methodName>
  <params>
    <param>
      <value>
        <struct>
          <member>
            <name>key</name>
            <value>00000000000000000000000000000000</value>
          </member>
          <member>
            <name>phrase</name>
            <value>britney speers</value>
          </member>
        </struct>
      </value>
    </param>
  </params>
</methodCall>

Что-то избыточности, по сравнению с SOAP, да еще и четырехкратной, не видно даже в микроскоп

S> H>Ну, во первых, у нашего далеко не одна. Но, конечно, с количеством инсталлей сквида не сравнить. Вот только проксями, в нашем не идеальном мире живых людей, пользуются очень и очень разными, а не из топ 3.

S> Да ладно. Ну расскажите мне, каковы шансы встретить экзотику, при наличии полностью бесплатных lighttpd и nginx.

О-о-о, на бескрайних просторах Российского энтерпрайза столько зверья встречается...

S> H>При том, что в codebase активикса указывается ссылка на *.inf, а уже в нем прописывается версия файла и прочие детали. Ну а хидеры... Да не вспомню я сейчас, что там в 2001 году было. Помню, хостилось оно все под IIS, и сношались мы с этой радостью очень долго. Кстати, потом в инете, я где-то находил подтверждение этой проблемы.

S> Ну да, проблемы 12летней давности, конечно же, актуальны при принятии архитектурных решений.

Предпочитаю думать заранее о том, где можно схлопотать по уху, а не испытывать удачу.

S> H>Откуда вдруг взялась невозможность потребления сервиса из тонкого клиента?

S> Не невозможность потребления сервиса, а невозможность пользования вашим велосипедным кэшированием.

А с чего вдруг? Интерфейс сервисов обычно описывается в документации, соответственно и механизм использования кэша будет описан.

S> H>Не нужно выдумывать. Я уже сказал, что для XML-RPC есть JS-реализации. Просто мы таких клиентов не делаем. И, кстати, WinInet'ом не пользуемся тоже.

S> Да я прекрасно понял уже ваше стремление к пессимизации приложений.

Просто наши интересы не ограничиваются рамками дефолт ОС, а потому WinInet ну ваще ни как

S> H>У меня есть опыт разработки веб-сервера с нуля, т.е. с уровня сокетов и пула потоков. Прокси для XML-RPC делается на его основе элементарно

S> То есть вот реально вы думаете, что авторы тупых HTTP-проксей неспособны сделать безглючную реализацию, а ваш умный прокси для XML-RPC легко сделать безошибочным? А, ну удачи.

Я этого не говорил. Я сказал, что в нашем не идеальном мире живых людей, уповать на непогрешимость сторонних и неизвестно каких продуктов я не решаюсь.

S> H>У нас такие приложения, что кэширование практически неприменимо

Но это не отрицает возможности его реализации в RPC.

S> Все так говорят. В прошлый раз, когда мне пытались привести пример приложения, где кэширование неприменимо, получилось смешно.
S> У вас не кэширование неприменимо, у вас потребности в высокой производительности нет.

Производительность у нас на первом месте. А еще конфиденциальность, с которой кэширование в контрах.

S> H>Вот так всегда, как только речь заходит о конкретике, сторонники REST вспоминают о каком-то одном, конкретном, REST-фреймвоке

S> H>На размер URI разумеется.

S> Ссылочку на ограничение размера URI в дефолтных реализациях не затруднит?

Ссылка на вики:

Браузеры имеют ограничения по длине URL, что определяет максимальный размер данных. Например, URI в Опере имели предел 4 КБ, а в Internet Explorer около 2 КБ.

Естественно, что, и прокси, и веб-серверы могут иметь свои ограничения (414 Request-URI to long).

S> H>Я тебе уже как-то показывал, насколько хорошо решает сжатие, как раз таки на примере с base64.

S> На примере с реальными данными сжатие работает ещё лучше.

А там и был пример с реальными данными.

S> H>Это заблуждение. Клиент XML-RPC или JSON-RPC сервиса получив вместо 200 OK, 301 или 307 преспокойно сменит endpoint на указанный в location. Никакой драмы и трагедии нет.

S> Сначала нужно чтобы кто-то отдал этот 301 или 307. Я же говорю — вам нужен Load Balancer, а он не бесплатен.

Умные ноды с синхронизацией состояния по нагрузке далеко не рокетсайнсовая штука.

avalon 1.0rc3 build 432, zlib 1.2.5

Здравствуйте, hattab, Вы писали:
H>Когда ты говоришь о нулевой латентности, ты имеешь ввиду кэш основанный на временнЫх метках.
Отож.
H>в случае с кэшированием ориентированным на ETag (те случаи, когда актуализация данных на клиенте критична) от полного раундтрипа ты не избавлен.
Но как минимум я имею экономию на body.
H>Ну и о якобы избыточности XML-RPC. Вот живой пример использования гуглового сервиса:

H>SOAP (582 байта, без индентинга 549):
H>

H><?xml version='1.0' encoding='UTF-8'?>
H><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
H>  <SOAP-ENV:Body>
H>    <ns1:doSpellingSuggestion xmlns:ns1="urn:GoogleSearch"
H>        SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
H>      <key xsi:type="xsd:string">00000000000000000000000000000000</key>
H>      <phrase xsi:type="xsd:string">britney speers</phrase>
H>    </ns1:doSpellingSuggestion>
H>  </SOAP-ENV:Body>
H></SOAP-ENV:Envelope>
H>

H>А так выглядел бы вариант для XML-RPC (294 байт, без индентинга 260):
H>

H><?xml version="1.0" encoding="utf-8"?>
H><methodCall>
H>  <methodName>google.doSpellingSuggestion</methodName>
H>  <params>
H>    <param>
H>      <value>00000000000000000000000000000000</value>
H>    </param>
H>    <param>
H>      <value>britney speers</value>
H>    </param>
H>  </params>
H></methodCall>
H>

Это вам повезло, что оба параметра оказались строковыми. Как только начнёте передавать не-строки, всё станет интереснее.

H>Что-то избыточности, по сравнению с SOAP, да еще и четырехкратной, не видно даже в микроскоп

Простите, перепутал. Не с SOAP, а с plain XML. Посыпаю голову пеплом.
Ну давайте заодно сравним с REST. Вот body нужного нам реквеста:

0 байт против ваших 260.
Ну, то есть понятно, что у нас удлинится URL. В предположении, что адрес точки входа один и тот же, мы дополнительно потратим 69 байт (/doSpellingSuggestion/00000000000000000000000000000000/britney+speers).Из них — 3 байта на разметку, остальное — пользовательские данные.

Итого имеем 260/69 ~ четырёхкратную избыточность XML-RPC по сравнению с REST.
И это вам повезло, что оба параметра — строки. Если действовать строго по стандарту, не опуская необязательные type tags, то получится

<methodCall>
  <methodName>google.doSpellingSuggestion</methodName>
  <params>
    <param>
      <value><string>00000000000000000000000000000000</string></value>
    </param>
    <param>
      <value><string>britney speers</string></value>
    </param>
  </params>
</methodCall>

т.е. 294 байта без индентинга.
H>О-о-о, на бескрайних просторах Российского энтерпрайза столько зверья встречается...
И оно прямо-таки нарушает устаканенные RFC? Можно зоть какой-то пруф в студию? Я сходу не нашёл известных багов в прокси-серверах.
Зато по "proxy serves stale data" легко находятся топики типа http://stackoverflow.com/questions/3091056/how-to-bypass-a-proxy-server-when-needed. Обратите внимание на ответ.

H>Предпочитаю думать заранее о том, где можно схлопотать по уху, а не испытывать удачу.
Думать надо не о том, где можно схлопотать по уху, а о том, как increase stakeholder value. Ваше отношение к прокси ("там живут драконы") не выглядит профессиональным.

H>А с чего вдруг? Интерфейс сервисов обычно описывается в документации, соответственно и механизм использования кэша будет описан.
С того вдруг, что в тонком клиенте доступ к local storage пока что очень ограничен, и нарисовать на нём полноценный кэш — дело тяжёлое. Одной "документации" тут недостаточно. Если не стараться пессимизировать сервис, а пользоваться изкоробочными возможностями, то тупой Get через XmlHttpRequest или JsHttpRequest проходит сквозь штатный кэш и выигрывает от наличия серверной реализации — на практически всех версиях браузеров, выпущенных за последние 10 лет.

H>Просто наши интересы не ограничиваются рамками дефолт ОС, а потому WinInet ну ваще ни как

Ну, это аргумент. Не глядя в хрустальный шар, сходу задумываюсь над двумя ответами: "Java" и "тонкий клиент". Про второй мы уже поговорили.

H>Я этого не говорил. Я сказал, что в нашем не идеальном мире живых людей, уповать на непогрешимость сторонних и неизвестно каких продуктов я не решаюсь.
Вы не готовы уповать на непогрешимость industry-proven продуктов, зато готовы уповать на свою. Это я уже понял.
H>Производительность у нас на первом месте. А еще конфиденциальность, с которой кэширование в контрах.
Нет никаких контров. Нужно просто понимать scope кэширования. Конфиденциальность "мешает" только при кэшировании на server side, зато она прекрасно применима на client side.

H>Для XML-аллергиков есть JSON-RPC. Хотя можете и пешком, вам, REST-проповедникам оно привычно

Он не намного лучше. В том смысле, что предлагает совершенно надуманные ограничения в обмен на наличие "стандартных" инструментов, которые при их отсутствии (в отличие от кэширующего сервера) пишутся на коленке за час. Вы серьёзно полагаете, что парсинг XML или JSON, содержащих машинночитаемую инфу об ошибке, сколь-нибудь затруднит разработчика клиента?

H>Ссылка на вики:
H>

Браузеры имеют ограничения по длине URL, что определяет максимальный размер данных. Например, URI в Опере имели предел 4 КБ, а в Internet Explorer около 2 КБ.

Вы же мне только что рассказывали, что не пишете браузерные приложения. Почему вас тогда беспокоят проблемы IE, неспособного к обработке длинных URL?

H>Естественно, что, и прокси, и веб-серверы могут иметь свои ограничения (414 Request-URI to long).
Ссылочку на реальные ограничения реальных прокси и веб серверов в студию не затруднит?
Потому что если рассуждать в терминах 414, то есть и 413.

S>> На примере с реальными данными сжатие работает ещё лучше.

H>А там и был пример с реальными данными.
Угу. А я бы ещё посмотрел, сколько этот "отфонарный скриншот" занимает в .png. Чисто чтобы показать, что выбор адекватного формата представления данных рулит не так слабо, как кажется.

H>Умные ноды с синхронизацией состояния по нагрузке далеко не рокетсайнсовая штука.
Опять мы говорим про отказ от industry-proven и straightforward решений в пользу жутких костылей лишь на том основании, что "потенциально это можно написать".

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

S> H>Когда ты говоришь о нулевой латентности, ты имеешь ввиду кэш основанный на временнЫх метках.

S> Отож.

Оно мало где применимо вообще

В многопользовательской системе ориентированной не на одну лишь перлюстрацию данных этот тип кэширования будет просто не востребован.

S> H>в случае с кэшированием ориентированным на ETag (те случаи, когда актуализация данных на клиенте критична) от полного раундтрипа ты не избавлен.

S> Но как минимум я имею экономию на body.

Обычно, тело запросов на получение данных не является большим, так что экономии там чуть

S> Это вам повезло, что оба параметра оказались строковыми. Как только начнёте передавать не-строки, всё станет интереснее.

Спецификаторы типов там короткие, разве что у даты длинноват. Но мы же понимаем, что сжатие все эти повторяющиеся паттерны нивелирует, а без сжатия текстовые протоколы используются крайне редко.

S> Ну давайте заодно сравним с REST. Вот body нужного нам реквеста:
S> 0 байт против ваших 260.
S> Ну, то есть понятно, что у нас удлинится URL. В предположении, что адрес точки входа один и тот же, мы дополнительно потратим 69 байт (/doSpellingSuggestion/00000000000000000000000000000000/britney+speers).Из них — 3 байта на разметку, остальное — пользовательские данные.

S> Итого имеем 260/69 ~ четырёхкратную избыточность XML-RPC по сравнению с REST.

Если учесть, что мы используем сжатие, то в gzip этот запрос будет весить всего 149 байт (запрос сериализован одной строкой + отсутствует ненужная декларация кодировки). Итого: 149/69, всего в два раза. Да и что вообще такое дополнительные 80 байт

S> И это вам повезло, что оба параметра — строки. Если действовать строго по стандарту, не опуская необязательные type tags, то получится
S>

S> <methodCall>
S>   <methodName>google.doSpellingSuggestion</methodName>
S>   <params>
S>     <param>
S>       <value><string>00000000000000000000000000000000</string></value>
S>     </param>
S>     <param>
S>       <value><string>britney speers</string></value>
S>     </param>
S>   </params>
S> </methodCall>
S>

S> т.е. 294 байта без индентинга.

Действуя строго по стандарту, указывать тип для строк мы не обязаны. Тут ни каких нарушений нет.

S> H>О-о-о, на бескрайних просторах Российского энтерпрайза столько зверья встречается...

S> И оно прямо-таки нарушает устаканенные RFC? Можно зоть какой-то пруф в студию? Я сходу не нашёл известных багов в прокси-серверах.
S> Зато по "proxy serves stale data" легко находятся топики типа http://stackoverflow.com/questions/3091056/how-to-bypass-a-proxy-server-when-needed. Обратите внимание на ответ.

Не, претензий к конкретным проксям у меня нет. Но есть прокси позволяющие регулировать механизм кэширования, и админы склонны этим пользоваться. Пример (! только, как пример) такого прокси HandyCache, там все так зарегулировать можно...

S> H>Предпочитаю думать заранее о том, где можно схлопотать по уху, а не испытывать удачу.

S> Думать надо не о том, где можно схлопотать по уху, а о том, как increase stakeholder value. Ваше отношение к прокси ("там живут драконы") не выглядит профессиональным.

Огрести проблемы можно не только с проксями, некоторые фаеры режут незнакомые/запрещенные/подозрительные для них заголовки HTTP (легко гуглится). Так что, и там тоже драконы живут. У-у-у-у

S> H>А с чего вдруг? Интерфейс сервисов обычно описывается в документации, соответственно и механизм использования кэша будет описан.

S> С того вдруг, что в тонком клиенте доступ к local storage пока что очень ограничен, и нарисовать на нём полноценный кэш — дело тяжёлое. Одной "документации" тут недостаточно. Если не стараться пессимизировать сервис, а пользоваться изкоробочными возможностями, то тупой Get через XmlHttpRequest или JsHttpRequest проходит сквозь штатный кэш и выигрывает от наличия серверной реализации — на практически всех версиях браузеров, выпущенных за последние 10 лет.

Вот я и не понимаю, нафига страдать с тонкими (браузерными) клиентами, когда можно взять, что потолще

У нас таких клиентов нет, кроме админки на флексе, но там, насколько мне известно (не моя тема), с локальным стореджем проблем нет.

S> H>Просто наши интересы не ограничиваются рамками дефолт ОС, а потому WinInet ну ваще ни как

S> Ну, это аргумент. Не глядя в хрустальный шар, сходу задумываюсь над двумя ответами: "Java" и "тонкий клиент". Про второй мы уже поговорили.

Java слишком много хотеть кушать. У нас Delphi + FPC + Flex, пока все устраивает.

S> H>Я этого не говорил. Я сказал, что в нашем не идеальном мире живых людей, уповать на непогрешимость сторонних и неизвестно каких продуктов я не решаюсь.

S> Вы не готовы уповать на непогрешимость industry-proven продуктов, зато готовы уповать на свою. Это я уже понял.

С проблемами своих мы как нибудь разберемся, с проблемами сторонних увы. Даже если это проблемы излишнего конфигурирования (мир то не идеальный) огребать от них все равно не хочется.

S> H>Производительность у нас на первом месте. А еще конфиденциальность, с которой кэширование в контрах.

S> Нет никаких контров. Нужно просто понимать scope кэширования. Конфиденциальность "мешает" только при кэшировании на server side, зато она прекрасно применима на client side.

Если где-то на проксях осядет интересный документ это будет нехорошо.

S> H>Для XML-аллергиков есть JSON-RPC. Хотя можете и пешком, вам, REST-проповедникам оно привычно

S> Он не намного лучше. В том смысле, что предлагает совершенно надуманные ограничения в обмен на наличие "стандартных" инструментов, которые при их отсутствии (в отличие от кэширующего сервера) пишутся на коленке за час. Вы серьёзно полагаете, что парсинг XML или JSON, содержащих машинночитаемую инфу об ошибке, сколь-нибудь затруднит разработчика клиента?

Я считаю, что формат обмена должен быть стандартизирован, и чем проще он будет тем лучше. XML-RPC и JSON-RPC этот вопрос закрывают и давно уже вышли за рамки взаимодействия веб-сервисов, сейчас они применяются и в качестве IPC.

S> H>Ссылка на вики:
S> H>

Браузеры имеют ограничения по длине URL, что определяет максимальный размер данных. Например, URI в Опере имели предел 4 КБ, а в Internet Explorer около 2 КБ.

S> Вы же мне только что рассказывали, что не пишете браузерные приложения. Почему вас тогда беспокоят проблемы IE, неспособного к обработке длинных URL?

Да, мы таких клиентов не пишем. Но я же на твой вопрос отвечаю.

S> H>Естественно, что, и прокси, и веб-серверы могут иметь свои ограничения (414 Request-URI to long).

S> Ссылочку на реальные ограничения реальных прокси и веб серверов в студию не затруднит?

Я вопрос не изучал специально, но гуглится легко.

S> Потому что если рассуждать в терминах 414, то есть и 413.

Определенно, проблема большого тела запроса существует. Но, по всем здравым размышлениями, размер тела запроса будет несоизмеримо больше, нежели размер идентификатора ресурса, который не предназначен для передачи данных.

S> H>А там и был пример с реальными данными.

S> Угу. А я бы ещё посмотрел, сколько этот "отфонарный скриншот" занимает в .png. Чисто чтобы показать, что выбор адекватного формата представления данных рулит не так слабо, как кажется.

Я знал, что ты это попросишь

Остался у меня и тот скриншот и весь тестовый проектик

В общем, дело обстоит так. Тот самый скриншот:

Отфонарный скриншот моего десктопа ужатый до 320x200x24, в формате BMP

пожатый в png (безо всякой дополнительной меты, с максимальным сжатием) занимает 49443 байта, респонзовый пакет XML-RPC с этим же png и пожатый gzip'ом занимает 49878. Итого, разница аж в 435 байтов. Как видим, вывод, по ссылке, актуальности не потерял

S> H>Умные ноды с синхронизацией состояния по нагрузке далеко не рокетсайнсовая штука.

S> Опять мы говорим про отказ от industry-proven и straightforward решений в пользу жутких костылей лишь на том основании, что "потенциально это можно написать".

Да нет, мы просто не повторяем чужие мантры о плохой масштабируемости решений основанных на RPC.

avalon 1.0rc3 build 432, zlib 1.2.5

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

H>Оно мало где применимо вообще

В многопользовательской системе ориентированной не на одну лишь перлюстрацию данных этот тип кэширования будет просто не востребован.
Оно очень много где применимо. Вы просто плохо ищете.

H>Обычно, тело запросов на получение данных не является большим, так что экономии там чуть

При чём тут запрос на получение? Я говорю про тело response, которое вообще не приезжает в случае 304.

H>Если учесть, что мы используем сжатие, то в gzip этот запрос будет весить всего 149 байт (запрос сериализован одной строкой + отсутствует ненужная декларация кодировки). Итого: 149/69, всего в два раза. Да и что вообще такое дополнительные 80 байт

Это двукратный рост трафика на ровном месте. Мы всё ещё про утилизацию канала, не забыли?

H>Действуя строго по стандарту, указывать тип для строк мы не обязаны. Тут ни каких нарушений нет.
Это я не про нарушения, а про то, что менее строковые API резко станут более избыточными. Можно ознакомиться с примерами "нашего" XML-RPC API. Вот, скажем, как выглядит целый orderID для ордера, добавленного в PBA:

<?xml version="1.0"?>
 <methodResponse>
  <params>
   <param>
    <value>
     <struct>
      <member>
       <name>Result</name>
        <value>
         <array>
          <data>
           <value>
            <array>
             <data>
              <!--Placed order ID -->
              <value><i4>22</i4></value>
            </data>
           </array>
          </value>
         </data>
        </array>
       </value>
      </member>
     </struct>
    </value>
   </param>
  </params>
 </methodResponse>

S>> H>О-о-о, на бескрайних просторах Российского энтерпрайза столько зверья встречается...

S>> И оно прямо-таки нарушает устаканенные RFC? Можно зоть какой-то пруф в студию? Я сходу не нашёл известных багов в прокси-серверах.
S>> Зато по "proxy serves stale data" легко находятся топики типа http://stackoverflow.com/questions/3091056/how-to-bypass-a-proxy-server-when-needed. Обратите внимание на ответ.

H>Не, претензий к конкретным проксям у меня нет. Но есть прокси позволяющие регулировать механизм кэширования, и админы склонны этим пользоваться. Пример (! только, как пример) такого прокси HandyCache, там все так зарегулировать можно...

S>> H>Предпочитаю думать заранее о том, где можно схлопотать по уху, а не испытывать удачу.

S>> Думать надо не о том, где можно схлопотать по уху, а о том, как increase stakeholder value. Ваше отношение к прокси ("там живут драконы") не выглядит профессиональным.

H>Огрести проблемы можно не только с проксями, некоторые фаеры режут незнакомые/запрещенные/подозрительные для них заголовки HTTP (легко гуглится). Так что, и там тоже драконы живут. У-у-у-у

S>> H>А с чего вдруг? Интерфейс сервисов обычно описывается в документации, соответственно и механизм использования кэша будет описан.

S>> С того вдруг, что в тонком клиенте доступ к local storage пока что очень ограничен, и нарисовать на нём полноценный кэш — дело тяжёлое. Одной "документации" тут недостаточно. Если не стараться пессимизировать сервис, а пользоваться изкоробочными возможностями, то тупой Get через XmlHttpRequest или JsHttpRequest проходит сквозь штатный кэш и выигрывает от наличия серверной реализации — на практически всех версиях браузеров, выпущенных за последние 10 лет.

H>Вот я и не понимаю, нафига страдать с тонкими (браузерными) клиентами, когда можно взять, что потолще

У нас таких клиентов нет, кроме админки на флексе, но там, насколько мне известно (не моя тема), с локальным стореджем проблем нет.

S>> H>Просто наши интересы не ограничиваются рамками дефолт ОС, а потому WinInet ну ваще ни как

S>> Ну, это аргумент. Не глядя в хрустальный шар, сходу задумываюсь над двумя ответами: "Java" и "тонкий клиент". Про второй мы уже поговорили.

H>Java слишком много хотеть кушать. У нас Delphi + FPC + Flex, пока все устраивает.

S>> H>Я этого не говорил. Я сказал, что в нашем не идеальном мире живых людей, уповать на непогрешимость сторонних и неизвестно каких продуктов я не решаюсь.

S>> Вы не готовы уповать на непогрешимость industry-proven продуктов, зато готовы уповать на свою. Это я уже понял.

H>С проблемами своих мы как нибудь разберемся, с проблемами сторонних увы. Даже если это проблемы излишнего конфигурирования (мир то не идеальный) огребать от них все равно не хочется.

S>> H>Производительность у нас на первом месте. А еще конфиденциальность, с которой кэширование в контрах.

S>> Нет никаких контров. Нужно просто понимать scope кэширования. Конфиденциальность "мешает" только при кэшировании на server side, зато она прекрасно применима на client side.

H>Если где-то на проксях осядет интересный документ это будет нехорошо.

S>> H>Для XML-аллергиков есть JSON-RPC. Хотя можете и пешком, вам, REST-проповедникам оно привычно

S>> Он не намного лучше. В том смысле, что предлагает совершенно надуманные ограничения в обмен на наличие "стандартных" инструментов, которые при их отсутствии (в отличие от кэширующего сервера) пишутся на коленке за час. Вы серьёзно полагаете, что парсинг XML или JSON, содержащих машинночитаемую инфу об ошибке, сколь-нибудь затруднит разработчика клиента?

H>Я считаю, что формат обмена должен быть стандартизирован, и чем проще он будет тем лучше. XML-RPC и JSON-RPC этот вопрос закрывают и давно уже вышли за рамки взаимодействия веб-сервисов, сейчас они применяются и в качестве IPC.

S>> H>Ссылка на вики:
S>> H>

Браузеры имеют ограничения по длине URL, что определяет максимальный размер данных. Например, URI в Опере имели предел 4 КБ, а в Internet Explorer около 2 КБ.

H>Я вопрос не изучал специально, но гуглится легко.
Отлично. Эта страница наглядно показывает, что можно спокойно использовать URL, достаточно длинные for any practical purpose.
В частности, Апач и IIS конфигурируются, и успешно жуют урлы длиной свыше 100KB.
Это уж если вам так хочется порассуждать о статус коде 414.
И уж во всяком случае принимать архитектурные решения на основе "я не знаю, но где-то слышал про какие-то проблемы" — моветон.

H>Определенно, проблема большого тела запроса существует. Но, по всем здравым размышлениями, размер тела запроса будет несоизмеримо больше, нежели размер идентификатора ресурса, который не предназначен для передачи данных.
Я не понимаю, о каких "здравых размышлениях" вы говорите. Есть стандарт, есть реализации, наблюдаемые в поле. Есть подвластная вам конфигурация, есть неподвластная. Есть конкретная задача, есть конкретные требования к интеропу. Только под это имеет смысл проектировать.
А принимать решения на основе "наверное, боди можно считать безлимитным, а URL — коротким" — простите, моветон. И к тому же противоречит вашему "мы сначала проектируем, а потом делаем".

H>Я знал, что ты это попросишь

Остался у меня и тот скриншот и весь тестовый проектик

В общем, дело обстоит так. Тот самый скриншот:
H>

Отфонарный скриншот моего десктопа ужатый до 320x200x24, в формате BMP

Ок, отлично. Снимаю свой аргумент с утилизацией канала за счёт многословности — она всего лишь будет жрать память на клиенте и на сервере.

H>Да нет, мы просто не повторяем чужие мантры о плохой масштабируемости решений основанных на RPC.
Давайте отступим на шаг назад. Весь спор сводится к тому, что XML-RPC предлагает "из коробки" одни фичи, а REST — другие фичи.
Понятно, что в обоих случаях недостающие фичи можно дописать.
Мой поинт — в том, что "недостающие" фичи в REST вообще не стоят упоминания — парсинг и генерация контента в XML или JSON на современных Фреймворках практически бесплатен в терминах девелоперских ресурсов. Поэтому упрёки типа "ооо, мне придётся руками разбирать информацию об ошибке" мне смешны. Ну, то есть сами по себе они нормальны, полчаса работы это полчаса работы, но по сравнению с тем, что отсутствует в XML-RPC — это просто детский лепет.
Вы смело берётесь дописывать кэширование и load balancing. По моему опыту, эти вещи очень сложны в реализации. Вон, в Java 1.5 попытались прикрутить кэширование веб-респонсов. И не смогли: в официальной реализации — блокерная бага.
Сделать так, чтобы ваш кэш-сервер переживал отключение питания, и всё ещё после этого отдавал консистетные результаты — рокет сайнс. Учёт всех нюансов того, кому что можно кэшировать — рокет сайнс. И так далее.

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

S> H>Обычно, тело запросов на получение данных не является большим, так что экономии там чуть

S> При чём тут запрос на получение? Я говорю про тело response, которое вообще не приезжает в случае 304.

А, ну да. Ну так в XML-RPC возвращение нулевого результата 107 байт. Не велика беда

S> H>Если учесть, что мы используем сжатие, то в gzip этот запрос будет весить всего 149 байт (запрос сериализован одной строкой + отсутствует ненужная декларация кодировки). Итого: 149/69, всего в два раза. Да и что вообще такое дополнительные 80 байт

S> Это двукратный рост трафика на ровном месте. Мы всё ещё про утилизацию канала, не забыли?

Не забыли. А теперь скажи, что будет если искомая фраза будет не "britney speers", а "бритни спирс"? На сколько увеличится размер URI благодаря эскейпингу? (риторический вопрос). В случае с XML-RPC, нам достаточно будет указать национальную кодировку документа.

S> H>Действуя строго по стандарту, указывать тип для строк мы не обязаны. Тут ни каких нарушений нет.

S> Это я не про нарушения, а про то, что менее строковые API резко станут более избыточными. Можно ознакомиться с примерами "нашего" XML-RPC API. Вот, скажем, как выглядит целый orderID для ордера, добавленного в PBA:
S>

S> <?xml version="1.0"?>
S>  <methodResponse>
S>   <params>
S>    <param>
S>     <value>
S>      <struct>
S>       <member>
S>        <name>Result</name>
S>         <value>
S>          <array>
S>           <data>
S>            <value>
S>             <array>
S>              <data>
S>               <!--Placed order ID -->
S>               <value><i4>22</i4></value>
S>             </data>
S>            </array>
S>           </value>
S>          </data>
S>         </array>
S>        </value>
S>       </member>
S>      </struct>
S>     </value>
S>    </param>
S>   </params>
S>  </methodResponse>

S>

Ящитаю вложенность нужно увеличить для пущего эффекта

Не, ну, что за фигня, структура с единственным членом массивом и у того единственный элемент массив содержащий фактическое значение. Ладно, как бы там нибыло, после причесывания (однострочной сериализации и выкидывания комментария) и gzip'а ответ весит 155 байт. Прям ужас, какой-то

[оверквотинг скипед]

S> H>Я вопрос не изучал специально, но гуглится легко.

S> Отлично. Эта страница наглядно показывает, что можно спокойно использовать URL, достаточно длинные for any practical purpose.
S> В частности, Апач и IIS конфигурируются, и успешно жуют урлы длиной свыше 100KB.
S> Это уж если вам так хочется порассуждать о статус коде 414.

Это ты всем клиентам будешь рекомендовать переконфигурировать свои серверы? А что с прокси, вообще не понятно (я бы не исключал проблем в этом месте). Сейчас вот сделал GET на http://www.google.com/q(65536) и получил 413 Request Entity Too Large, а потом сделал GET на твой http://www.ietf.org/q(65536) и получил 414 Request-URI Too Large

Ну и потом, длинный URI это потенциальные двери для DDOS (погугли long url dos).

S> И уж во всяком случае принимать архитектурные решения на основе "я не знаю, но где-то слышал про какие-то проблемы" — моветон.

Речь не о принятии архитектурных решений (XML-RPC был выбран совсем не из-за обсуждаемых ограничений REST) а о том, что с такой проблемой столкнуться можно легко. Немного отойдя от темы, напомню, что тут, на rsdn, была веселая история с блокированием януса. Теперь прикинь, какова вероятность налететь на один из блокируемых паттернов при использовании base64 в URI. Сильно не нулевая. Так что это не просто страхи, а такой вот не идеальный мир.

S> H>Определенно, проблема большого тела запроса существует. Но, по всем здравым размышлениями, размер тела запроса будет несоизмеримо больше, нежели размер идентификатора ресурса, который не предназначен для передачи данных.

S> А принимать решения на основе "наверное, боди можно считать безлимитным, а URL — коротким" — простите, моветон. И к тому же противоречит вашему "мы сначала проектируем, а потом делаем".

Мы потому и не паримся ограничениями, что наши сервисы работают под нашим сервером, ну и подходим разумно к объемам запросов. Это, однако, не значит, что все XML-RPC сервисы могут этой темой не заморачиваться. Я только говорю, что у REST тут дела ни чуть не лучше.

S> Ок, отлично. Снимаю свой аргумент с утилизацией канала за счёт многословности — она всего лишь будет жрать память на клиенте и на сервере.

Если использовать тупой парсер построенный на DOM. Мы используем умный на SAX. Ну и гигабайты одним пакетом не передаем.

S> H>Да нет, мы просто не повторяем чужие мантры о плохой масштабируемости решений основанных на RPC.

S> Давайте отступим на шаг назад. Весь спор сводится к тому, что XML-RPC предлагает "из коробки" одни фичи, а REST — другие фичи.
S> Понятно, что в обоих случаях недостающие фичи можно дописать.
S> Мой поинт — в том, что "недостающие" фичи в REST вообще не стоят упоминания — парсинг и генерация контента в XML или JSON на современных Фреймворках практически бесплатен в терминах девелоперских ресурсов. Поэтому упрёки типа "ооо, мне придётся руками разбирать информацию об ошибке" мне смешны. Ну, то есть сами по себе они нормальны, полчаса работы это полчаса работы, но по сравнению с тем, что отсутствует в XML-RPC — это просто детский лепет.
S> Вы смело берётесь дописывать кэширование и load balancing. По моему опыту, эти вещи очень сложны в реализации. Вон, в Java 1.5 попытались прикрутить кэширование веб-респонсов. И не смогли: в официальной реализации — блокерная бага.
S> Сделать так, чтобы ваш кэш-сервер переживал отключение питания, и всё ещё после этого отдавал консистетные результаты — рокет сайнс. Учёт всех нюансов того, кому что можно кэшировать — рокет сайнс. И так далее.

Не-не. Все мои слова о возможности реализовать собственный механизм кэширования и балансировке не более чем примеры, на тезисы о невозможности реализации, или отсутствии оного в RPC. Мне не приходилось делать собственный механизм кэширования т.к. в наших задачах я не вижу ему места. С балансировкой опыт есть, но там все и правда просто, динамическое разделение пользователей по обслуживаемым нодам и миграция их профилей (будто для REST этого делать не нужно

). Ну и единый и простой стандарт на формат данных это такой очевидный рулез снижающий порог вхождения, что я даже не заню, как с этим можно спорить.

avalon 1.0rc3 build 432, zlib 1.2.5

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

H>А, ну да. Ну так в XML-RPC возвращение нулевого результата 107 байт. Не велика беда

Ну как же "нулевого". С 304 могут приехать дополнительные хидеры. Это если вы хотите реализовать полноценное кэширование, сравнимое со взрослыми реализациями.

H>Не забыли. А теперь скажи, что будет если искомая фраза будет не "britney speers", а "бритни спирс"? На сколько увеличится размер URI благодаря эскейпингу? (риторический вопрос). В случае с XML-RPC, нам достаточно будет указать национальную кодировку документа.
В данном конкретном случае "указание национальной кодировки документа" сожрёт ровно столько же байт, сколько и лишние байты в заенкоженном УРле.

S>> H>Действуя строго по стандарту, указывать тип для строк мы не обязаны. Тут ни каких нарушений нет.

H>Ящитаю вложенность нужно увеличить для пущего эффекта

По сравнению с 6 байтами — да, ужоснах.

H>[оверквотинг скипед]
Это я нечаянно не на всё ответил.
По поводу фаерволлов — жду в студию пример фаерволла, режущего "опасные" хидеры ETag, If-modified-since, if-none-match, Cache-Control и Expires.
Вы поймите, что боитесь пользоваться функциональностью, на которой работает 95% интернета. Просто традиционно эти функции прикручены к статике, а не к динамике. Потому что статику отдают сервера, написанные профессионалами и хорошо отлаженные. Те же content delivery networks напропалую используют продвинутые фишки протокола. И если кто-то где-то у себя открутит это дело, то уверяю вас — заметят и починят это очень быстро. Потому что навернётся повседневный експириенс, а не какие-то редкоиспользуемые приложения.
В итоге браузеры и сервера прекрасно работают друг с другом. А разработчики промежуточных слоёв боятся открыть спецификацию и прочитать — а вдруг оно не заработает! Вон доклад 1999 года...

H>Это ты всем клиентам будешь рекомендовать переконфигурировать свои серверы?
Кого мы в данном случае называем клиентами? Клиенты API обойдутся без серверов. А свой сервер я уж как-нибудь один раз переконфигурирую, делов-то.

H>А что с прокси, вообще не понятно (я бы не исключал проблем в этом месте). Сейчас вот сделал GET на http://www.google.com/q(65536) и получил 413 Request Entity Too Large, а потом сделал GET на твой http://www.ietf.org/q(65536) и получил 414 Request-URI Too Large

Ну и потом, длинный URI это потенциальные двери для DDOS (погугли long url dos).
Не смешите мои тапочки. Любой HTTP — это потенциальные двери для DDOS. Чем тут URI отличается от Body — в упор не понятно.

Да, ietf в своём сервере заранее знает, какие URL они собираются сёрвить. Они не давали обязательства обрабатывать любой URL, который придёт вам в голову. Поэтому они отдают 414, не пытаясь идти на диск в поисках документа с именем q(65536).
Мой сервер, реализующий REST-протокол, будет брать на себя другие обязательства. Ровно те, которые я на него возложу.
Если мне нужно уметь искать по картинке весом в 100MB, то независимо от выбора надстройки над HTTP мне нужно решить вопрос доставки такого объёма с клиента на сервер.

H>Речь не о принятии архитектурных решений (XML-RPC был выбран совсем не из-за обсуждаемых ограничений REST) а о том, что с такой проблемой столкнуться можно легко. Немного отойдя от темы, напомню, что тут, на rsdn, была веселая история с блокированием януса. Теперь прикинь, какова вероятность налететь на один из блокируемых паттернов при использовании base64 в URI. Сильно не нулевая. Так что это не просто страхи, а такой вот не идеальный мир.
Всяко ниже, чем при использовании обычных URL. Впрочем, я уже сказал, что не настаиваю на base64 в URL.

H>Мы потому и не паримся ограничениями, что наши сервисы работают под нашим сервером, ну и подходим разумно к объемам запросов. Это, однако, не значит, что все XML-RPC сервисы могут этой темой не заморачиваться. Я только говорю, что у REST тут дела ни чуть не лучше.
Конечно. У него дела лучше в других областях.

H>Не-не. Все мои слова о возможности реализовать собственный механизм кэширования и балансировке не более чем примеры, на тезисы о невозможности реализации, или отсутствии оного в RPC. Мне не приходилось делать собственный механизм кэширования т.к. в наших задачах я не вижу ему места. С балансировкой опыт есть, но там все и правда просто, динамическое разделение пользователей по обслуживаемым нодам и миграция их профилей (будто для REST этого делать не нужно

).
Для REST это делать тоже можно. Но там есть ещё и возможность тупо порезать object space на столько нод, сколько захочется. И в том числе делать это и динамически, т.к. вместо непрозрачных "object ID" в REST принято возвращать URI. И этот URI будет показывать туда, куда нам надо.

H>Ну и единый и простой стандарт на формат данных это такой очевидный рулез снижающий порог вхождения, что я даже не заню, как с этим можно спорить.
Очень просто. У REST порог вхождения существенно ниже, чем у XML-RPC. За счёт того, что браузер может работать вполне годным клиентом REST-сервиса, так что его можно поэксплорить не написав ни единой строчки кода.
Велкам в http://apscatalog.com/1.2/.
Формат данных — это пренебрежимо мелкий рулез. Потому что для реального сервиса важно понимать его модель, и ожидаемые от клиента действия.
Попробуйте понять, какой запрос нужно отправить клиентскому приложению этому сервису чтобы проверить, есть ли новые обновления для локально установленного конкретного пакета. Каковы шансы, что вы не сможете разобраться с этим безо всякой документации?
А каковы шансы на то, что вы, найдя нужный запрос, не сможете разобраться со стандартом atom?

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

S> H>А, ну да. Ну так в XML-RPC возвращение нулевого результата 107 байт. Не велика беда

S> Ну как же "нулевого". С 304 могут приехать дополнительные хидеры. Это если вы хотите реализовать полноценное кэширование, сравнимое со взрослыми реализациями.

Не, я о том, что XML-RPC по любому должен ответить нормальным респонзом, и если делать аналог 304 то сервер может возвращать значение nil. Такой пакет будет весить 107 байт.

S> H>Не забыли. А теперь скажи, что будет если искомая фраза будет не "britney speers", а "бритни спирс"? На сколько увеличится размер URI благодаря эскейпингу? (риторический вопрос). В случае с XML-RPC, нам достаточно будет указать национальную кодировку документа.

S> В данном конкретном случае "указание национальной кодировки документа" сожрёт ровно столько же байт, сколько и лишние байты в заенкоженном УРле.

??? Для URL национальные символы будут преобразованы в UTF-8 (нам же нужен универсальный механизм кодирования), а затем каждый байт заенкодится в шестнадцатиричное представление. В результате, "бритни спирс" превратится в "%D0%B1%D1%80%D0%B8%D1%82%D0%BD%D0%B8+%D1%81%D0%BF%D0%B8%D1%80%D1%81" (67 байт). Добавление encoding="windows-1251" увеличит размер пакета на 24 байта (при этом, русского текста там может содержаться сколь угодно много).

S> H>Ящитаю вложенность нужно увеличить для пущего эффекта

S> По сравнению с 6 байтами — да, ужоснах.

Ужоснах это приводить, в качестве примера, значение в тройной обертке

S> H>[оверквотинг скипед]

S> Это я нечаянно не на всё ответил.
S> По поводу фаерволлов — жду в студию пример фаерволла, режущего "опасные" хидеры ETag, If-modified-since, if-none-match, Cache-Control и Expires.

Так это может зависеть от настроек разной степени параноидальности

Я где-то читал, что аутпост резал кастомные хидеры использовавшиеся в SOAP. Помнишь, я приводил тут пример ответа амазоновского REST-сервиса? Там было два кастомных заголовка, и я не уверен, что с ними однажды не возникнет проблем. А погуглив, нашел и про Outpost кое что (и еще). Не идеальный мир такой не идеальный

S> Вы поймите, что боитесь пользоваться функциональностью, на которой работает 95% интернета. Просто традиционно эти функции прикручены к статике, а не к динамике. Потому что статику отдают сервера, написанные профессионалами и хорошо отлаженные. Те же content delivery networks напропалую используют продвинутые фишки протокола. И если кто-то где-то у себя открутит это дело, то уверяю вас — заметят и починят это очень быстро. Потому что навернётся повседневный експириенс, а не какие-то редкоиспользуемые приложения.
S> В итоге браузеры и сервера прекрасно работают друг с другом. А разработчики промежуточных слоёв боятся открыть спецификацию и прочитать — а вдруг оно не заработает! Вон доклад 1999 года...

Да мы не боимся, я же сказал, что выбрали RPC совсем по другим причинам, а об этих траблах я говорю, коли уж разговор сюда зашел.

S> H>Это ты всем клиентам будешь рекомендовать переконфигурировать свои серверы?

S> Кого мы в данном случае называем клиентами? Клиенты API обойдутся без серверов. А свой сервер я уж как-нибудь один раз переконфигурирую, делов-то.

Ну вот у наших клиентов (заказчиков) работают наши сервисы, на нашем же сервере (не в смысле расположения). А раз уж ты говоришь об industry-proven получается, что вместо своего сервера нам бы стоило взять что-то из этого самого (возможно имеющегося у заказчика). Cледовательно им свои серверы переконфигурять?

S> H>А что с прокси, вообще не понятно (я бы не исключал проблем в этом месте). Сейчас вот сделал GET на http://www.google.com/q(65536) и получил 413 Request Entity Too Large, а потом сделал GET на твой http://www.ietf.org/q(65536) и получил 414 Request-URI Too Large

Ну и потом, длинный URI это потенциальные двери для DDOS (погугли long url dos).

S> Не смешите мои тапочки. Любой HTTP — это потенциальные двери для DDOS. Чем тут URI отличается от Body — в упор не понятно.

Дело может быть в обработке методов. Например, сервер ограничивает URI до 100 символов, а получив POST может предполагать, что сейчас будет большое тело запроса и изменить механизм чтения из сокета (например писать его сразу на диск или по достижении порогового значения). В случае, когда предполагается использование длинных URI серверу просто нечем защищаться и он может стать легкой мишенью.

S> Да, ietf в своём сервере заранее знает, какие URL они собираются сёрвить. Они не давали обязательства обрабатывать любой URL, который придёт вам в голову. Поэтому они отдают 414, не пытаясь идти на диск в поисках документа с именем q(65536).
S> Мой сервер, реализующий REST-протокол, будет брать на себя другие обязательства. Ровно те, которые я на него возложу.

Ты сейчас говоришь о своем сервере или таки industry-proven?

S> Если мне нужно уметь искать по картинке весом в 100MB, то независимо от выбора надстройки над HTTP мне нужно решить вопрос доставки такого объёма с клиента на сервер.

Угу. У нас это решается блочным доступом

S> H>Речь не о принятии архитектурных решений (XML-RPC был выбран совсем не из-за обсуждаемых ограничений REST) а о том, что с такой проблемой столкнуться можно легко. Немного отойдя от темы, напомню, что тут, на rsdn, была веселая история с блокированием януса. Теперь прикинь, какова вероятность налететь на один из блокируемых паттернов при использовании base64 в URI. Сильно не нулевая. Так что это не просто страхи, а такой вот не идеальный мир.

S> Всяко ниже, чем при использовании обычных URL. Впрочем, я уже сказал, что не настаиваю на base64 в URL.

Я бы не был так уверен

У меня тут была задача генерировать по некоторому алгоритму ключи для софта (ну, эти привычные XXXX-XXXXX-XXXXXX-XXXX). Алфавит, понятное дело, ограничен заглавной латиницей. Ну и чтобы не получилось некрасиво, каждый ключ проверялся на вхождение всяких там F#CK, A#AL, #EX и тому подобного... Ты не поверишь, на сотню ключей пара-тройка да попадала под фильтр

S> H>Не-не. Все мои слова о возможности реализовать собственный механизм кэширования и балансировке не более чем примеры, на тезисы о невозможности реализации, или отсутствии оного в RPC. Мне не приходилось делать собственный механизм кэширования т.к. в наших задачах я не вижу ему места. С балансировкой опыт есть, но там все и правда просто, динамическое разделение пользователей по обслуживаемым нодам и миграция их профилей (будто для REST этого делать не нужно

).

S> Для REST это делать тоже можно. Но там есть ещё и возможность тупо порезать object space на столько нод, сколько захочется. И в том числе делать это и динамически, т.к. вместо непрозрачных "object ID" в REST принято возвращать URI. И этот URI будет показывать туда, куда нам надо.

Как будто, кто-то мешает вернуть URI из RPC

S> H>Ну и единый и простой стандарт на формат данных это такой очевидный рулез снижающий порог вхождения, что я даже не заню, как с этим можно спорить.

S> Очень просто. У REST порог вхождения существенно ниже, чем у XML-RPC. За счёт того, что браузер может работать вполне годным клиентом REST-сервиса, так что его можно поэксплорить не написав ни единой строчки кода.
S> Велкам в http://apscatalog.com/1.2/.
S> Формат данных — это пренебрежимо мелкий рулез. Потому что для реального сервиса важно понимать его модель, и ожидаемые от клиента действия.
S> Попробуйте понять, какой запрос нужно отправить клиентскому приложению этому сервису чтобы проверить, есть ли новые обновления для локально установленного конкретного пакета. Каковы шансы, что вы не сможете разобраться с этим безо всякой документации?
S> А каковы шансы на то, что вы, найдя нужный запрос, не сможете разобраться со стандартом atom?

Стандартный формат позволяет документации на сервис говорить с разработчиком клиента на понятном им обоим языке. Если документация говорит:

RPC endpoint: http://foxrate.org/rpc/

Method name: foxrate.currencyConvert

Parameters:
from currency (eg: USD) = string
to currency (eg: GBP) = string
amount to convert (eg:100.0) = float

У разработчика на XML-RPC не возникает ни каких вопросов по тому, каким образом нужно передать имя метода, как передавать параметры, как указать тип параметров и нужно ли вообще это делать. Он знает, что такое структура в терминах протокола. Он знает, что такое массив и бинарные данные. Он знает, как форматируются числа с плавающей точкой. Он знает, как будет выглядеть этот вызов в XML. Он знает, что может сделать:

 XmlRpcServer('http://foxrate.org/rpc/').foxrate.currencyConvert('USD', 'RUB', 1.0)

и получит результат. Все. Никакого информационного шума о форматах и способах передачи. Либо же он просто собирает любым доступным способ XML-пакет в едином формате и так же доступным способом отправляет на сервер. Аллилуйя!

avalon 1.0rc3 build 432, zlib 1.2.5

От:	Sinclair	https://github.com/evilguest/
Дата:	29.01.13 09:45
Оценка:

	От:	hattab
	Дата:	29.01.13 18:06
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	30.01.13 06:27
Оценка:

	От:	hattab
	Дата:	30.01.13 11:24
	Оценка:	-1

От:	Sinclair	https://github.com/evilguest/
Дата:	31.01.13 07:45
Оценка: