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

H>Ну как же не существует,
Вот так и не существует. Нету формального определения объекта in programming term.

H>Object in programming term это те самые объекты из ООП. Понятнее некуда, кмк.
Так в ООП или в programming term? можешь еще, кстати, определение ООП попробовать найти, тоже много забавного.
Еще раз, сказать "object in programming term" — это значит ни сказать ничего, так как в programming term под object-ом каждый понимает свое в зависимости от контекста. Формальное определение отсутствует.

H>Вот-вот. Stateful в полный рост
Ты хорошо понимаешь значение слова stateful? В этом случае и REST stateful, так как буковка S в этой аббревиатуре означает state.
На всякий случай, под stateful понимает сохранение состояния между вызовами, а не передача состояния удаленной стороны.
Вот тебе идеология SOAP из того же документа: "SOAP is fundamentally a stateless, one-way message exchange paradigm"

К слову об идеологической общности SOAP (... the state of some resource) REST (Representation State Transfer) — найдите десять отличий.

Как я уже говорил, разница лишь в том, что вокруг SOAP навернули дофига готовых Фреймворков разной степени совместимости, а REST, по факту, лишь набор весьма условных соглашений, по которым каждый должен все выпиливать в ручную.

H>Конечно правда.
Ну, я не в состоянии помешать тебе пребывать в этом заблуждении )

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

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

S>Иван, ты не ткнёш меня носом в кэширование для SOAP? Я что-то не в курсе, каким образом его можно туда прикрутить.
Вот отличная статья, прекрасно подтвержающая твою точку зрения:
http://weblogs.asp.net/cibrax/archive/2011/05/18/caching-strategies-for-soap-and-rest-services.aspx
=))

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

IB> Вот так и не существует. Нету формального определения объекта in programming term.

IB> H>Object in programming term это те самые объекты из ООП. Понятнее некуда, кмк.

IB> Так в ООП или в programming term? можешь еще, кстати, определение ООП попробовать найти, тоже много забавного.
IB> Еще раз, сказать "object in programming term" — это значит ни сказать ничего, так как в programming term под object-ом каждый понимает свое в зависимости от контекста. Формальное определение отсутствует.

Еще как существует

IB> H>Вот-вот. Stateful в полный рост

IB> Ты хорошо понимаешь значение слова stateful? В этом случае и REST stateful, так как буковка S в этой аббревиатуре означает state.
IB> На всякий случай, под stateful понимает сохранение состояния между вызовами, а не передача состояния удаленной стороны.

Именно так и понимаю.

IB> Вот тебе идеология SOAP из того же документа: "SOAP is fundamentally a stateless, one-way message exchange paradigm"

А дальше, что не цитируешь:

but applications can create more complex interaction patterns (e.g., request/response, request/multiple responses, etc.) by combining such one-way exchanges with features provided by an underlying protocol and/or application-specific information. SOAP is silent on the semantics of any application-specific data it conveys, as it is on issues such as the routing of SOAP messages, reliable data transfer, firewall traversal, etc. However, SOAP provides the framework by which application-specific information may be conveyed in an extensible manner. Also, SOAP provides a full description of the required actions taken by a SOAP node on receiving a SOAP message.

IB> Как я уже говорил, разница лишь в том, что вокруг SOAP навернули дофига готовых Фреймворков разной степени совместимости, а REST, по факту, лишь набор весьма условных соглашений, по которым каждый должен все выпиливать в ручную.

Так ты хочешь говорить о таком примитиве, как обмен сообщениями, и только его называть SOAP? Я предпочитаю говорить о SOAP, в той мере, в которой говорит о нем спецификация.

IB> H>Конечно правда.

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

Когда клиент и сервер оба работающие, вроде бы, по SOAP, не могут договориться, это не заблуждение. Это суровая реальность.

IB> H>Альтернативы всемогущности SOAP? А кому она нужна?

IB> Причем тут всемогущность? SOAP на отлично решает вполне конкретные прикладные задачи. Их класс не на столько широк, как изначально было задумано, но тем не менее, альтернативой SOAP-у в этих сценариях, является изнурительное ручное выпиливание с неизвестным результатом. Выбор очевиден.

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

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

H>Еще как существует
Ага, и еще сотня точно таких же, но других. В каждой книжке дается свое собственное уникальное определение объекта и ООП. Так что нет — никак не существует.
Особенно там хорош пассаж про объект в ООП...

H>Именно так и понимаю.
что-то не похоже, иначе бы к state в определении не примотался.

H>А дальше, что не цитируешь:
А дальше и не надо. Если внимательно прочтешь, то что сам же и процитировал, то увидишь, что там речь идет не про идеологию SOAP, а про то, что дальше _приложения_ могут с этим делать. Ровно то же самое они могут и с REST, было бы желание.

H>Так ты хочешь говорить о таком примитиве, как обмен сообщениями, и только его называть SOAP? Я предпочитаю говорить о SOAP, в той мере, в которой говорит о нем спецификация.
Спецификация только об обмене сообщениями и говорит.

H>Когда клиент и сервер оба работающие, вроде бы, по SOAP, не могут договориться, это не заблуждение. Это суровая реальность.
Ты сам-то это видел или только на википедии вычитал? Еще раз — SOAP очень грамотно порезан за части. Начальные уровни — прекрасно между собой совместимы, как правило в реальной жизни этого достаточно.

H>Вполне конкретные прикладные задачи на отлично решаются и другими, более специализированными, средствами
Не решаются. Как я уже говорил, единственное специализированное средство — фигурная резьба зубочисткой по коду.

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

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

H>rpc.get(obj_id, date1, date2); // conditional
H>rpc.get(obj_id, offset, count); // partial
О, как интересно. И что, неужели у меня промежуточный HTTP-прокси поймёт такой запрос и внезапно вернёт результат без обращения к серверу, из своего локального кэша?
А можно мне теперь совместить оба сразу?
Ок, я так и думал — в RPC вы получаете четыре метода там, где я имел один.
Теперь можно садиться за проектирование механизма согласования уровней реализации между клиентом и сервером — чтобы клиент мог определить, что из этих опциональных методов поддерживается данным сервером, а что — нет.
H>Я не совсем понял почему SOAP, когда я все это время говорил о XML-RPC/JSON-RPC. И для того и для другого есть реализации на JS.
А, ну для XML-RPC да. Но там мы сразу теряем все инфраструктурные плюшки SOAP, получая сочетание всех недостатков RPC и REST.

H>Предположим сервис конвертирования картинок. Параметры: картинка, её content-type и content-type результирующей картинки. Результат — конвертированная в указанный тип картинка. В RPC вся работа будет заключаться в вызове единственного метода, и в случае неудачи анализе причины. 1. Неизвестный тип исходной картинки. 2. Неизвестный тип результирующей картинки. 3. Ошибка чтения картинки (как вариант несоответствие картинки указанному типу). В REST, по идее, сервер должен выругаться 415 кодом, а клиент гадать, к какому content-type у сервера претензии.
В REST, по идее, 415 код означает, что не поддерживается тип, переданный в request. Если не поддерживается запрошенный тип результирующей картинки, то нужно возвращать 406. Ну, а "ошибка чтения" — это по любому 400 Bad Request.
Я надеюсь, то, что упомянутые параметры будут передаваться в хидерах Content-Type и Accept, дополнительно пояснять не нужно?

H>Я, как и ранее, скажу за XML-RPC. Так вот, клиенту XML-RPC ничто не мешает (и даже вменяется в обязанность) реагировать на статус коды транспорта соответствующим образом.
Ну, ещё немного, и мы получим из вашего XML-RPC полноценный REST. Чо уж там — если статус коды стали поддерживать, то надо идти

Здравствуйте, IB, Вы писали:
IB>Как RPC можно использовать все что угодно (пытаться) с разной степенью успешности, в том числе и REST. Другое дело, что идеологически SOAP никогда не предполагалось использовать в качестве RPC и никогда под такие сценарии он не затачивался.
Извини, но я не могу с этим согласиться. Спецификация SOAP 1.1 явно пишет:

One of the design goals of SOAP is to encapsulate and exchange RPC calls using the extensibility and flexibility of XML

Это в 1.2 было решено порвать с позорным прошлым, и сделать вид, что RPC тут ни при чём. Но, как известно, текилу легко выпустить из бутылки, загнать её обратно — вот это проблема.

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

S>Извини, но я не могу с этим согласиться. Спецификация SOAP 1.1 явно пишет:
А спецификация 1.0? Я как бы исхожу из здравого предположения, что "SOAP is fundamentally a stateless, one-way message exchange paradigm...", как гласит нам все та же спецификация.

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

H>Небольшое уточнение: SOAP ≠ SOA. То есть, и SOAP, и REST, и всевозможные RPC — это все SOA.

Да. Мы это уже уточнили выше.

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

IB> H>Еще как существует

IB> Ага, и еще сотня точно таких же, но других. В каждой книжке дается свое собственное уникальное определение объекта и ООП. Так что нет — никак не существует.
IB> Особенно там хорош пассаж про объект в ООП...

Важна-то суть. Объект есть набор данных и объединенных с ними методов обработки. Все. Большего и не нужно. У SOAP в Design goals что написано?

A major design goal for SOAP is simplicity and extensibility. This means that there are several features from traditional messaging systems and distributed object systems that are not part of the core SOAP specification. Such features include
Distributed garbage collection
Boxcarring or batching of messages
Objects-by-reference (which requires distributed garbage collection)
Activation (which requires objects-by-reference)

Отличная демонстрация наличия stateful механики

IB> H>Именно так и понимаю.

IB> что-то не похоже, иначе бы к state в определении не примотался.

А ты бы почитал о каком state я говорил. Еще раз обращаю твое внимание на design goals, где значатся objects by reference.

IB> H>А дальше, что не цитируешь:

IB> А дальше и не надо. Если внимательно прочтешь, то что сам же и процитировал, то увидишь, что там речь идет не про идеологию SOAP, а про то, что дальше _приложения_ могут с этим делать. Ровно то же самое они могут и с REST, было бы желание.

Одно дело, когда все эти навороты обозначаются в спеке, и другое дело, когда просто имеется возможность выразить оные имеющимися средствами.

IB> H>Так ты хочешь говорить о таком примитиве, как обмен сообщениями, и только его называть SOAP? Я предпочитаю говорить о SOAP, в той мере, в которой говорит о нем спецификация.

IB> Спецификация только об обмене сообщениями и говорит.

Все можно назвать обменом сообщениями, но важно за деревьями видеть лес. Спека говорит и об RPC, и о сервисах обработки сообщений и многом другом.

IB> H>Когда клиент и сервер оба работающие, вроде бы, по SOAP, не могут договориться, это не заблуждение. Это суровая реальность.

IB> Ты сам-то это видел или только на википедии вычитал? Еще раз — SOAP очень грамотно порезан за части. Начальные уровни — прекрасно между собой совместимы, как правило в реальной жизни этого достаточно.

Я, слава Яхве, очень мало работал с SOAP, буквально пару раз. Но в интернете полно обсуждений несовместимости SOAP, а дыма без огня не бывает. Навскидку мнение1, мнение2. 1С vs. Java Даже тут на сайте были вопросы по совместимости SOAP

Автор:
Дата: 08.11.10

IB> H>Вполне конкретные прикладные задачи на отлично решаются и другими, более специализированными, средствами

IB> Не решаются. Как я уже говорил, единственное специализированное средство — фигурная резьба зубочисткой по коду.

Ох, ё... Серебрянная пуля наконец-то отлита

IB> H> Зачем нужно связываться с монстром с многотонной спецификацией...

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

Ага, до первого рифа Да и вообще, ты так говоришь, будто ни для чего другого, окромя SOAP, фреймвоков и тулкитов не существует

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

S> H>rpc.get(obj_id, date1, date2); // conditional
S> H>rpc.get(obj_id, offset, count); // partial

S> О, как интересно. И что, неужели у меня промежуточный HTTP-прокси поймёт такой запрос и внезапно вернёт результат без обращения к серверу, из своего локального кэша?

Нет конечно, как и не будет проблем с чрезмерно активно кеширующим прокси. Да-да, не в идеальном мире живем.

S> А можно мне теперь совместить оба сразу?

Конечно можно. Если это вообще требуется в решаемой задаче

S> Ок, я так и думал — в RPC вы получаете четыре метода там, где я имел один.
S> Теперь можно садиться за проектирование механизма согласования уровней реализации между клиентом и сервером — чтобы клиент мог определить, что из этих опциональных методов поддерживается данным сервером, а что — нет.

Отчего-же опциональных? Внешний интерфейс он есть штука целостная (на то он и интерфейс, контракт т.е.), как спроектировал так и будет.

S> H>Я не совсем понял почему SOAP, когда я все это время говорил о XML-RPC/JSON-RPC. И для того и для другого есть реализации на JS.

S> А, ну для XML-RPC да. Но там мы сразу теряем все инфраструктурные плюшки SOAP, получая сочетание всех недостатков RPC и REST.

Какие это плюшки мы теряем? У XML-RPC есть интроспекция, вполне себе аналог WSDL. А тулкиты умели генерировать код еще в бородатых девяностых. Другое дело, что интроспекция не является частью протокола, а реализуется по желанию, как один из сервисов. Но она вполне себе стандартизирована сообществом, что важнее стандартизации неким комитетом.

S> H>Предположим сервис конвертирования картинок. Параметры: картинка, её content-type и content-type результирующей картинки. Результат — конвертированная в указанный тип картинка. В RPC вся работа будет заключаться в вызове единственного метода, и в случае неудачи анализе причины. 1. Неизвестный тип исходной картинки. 2. Неизвестный тип результирующей картинки. 3. Ошибка чтения картинки (как вариант несоответствие картинки указанному типу). В REST, по идее, сервер должен выругаться 415 кодом, а клиент гадать, к какому content-type у сервера претензии.

S> В REST, по идее, 415 код означает, что не поддерживается тип, переданный в request. Если не поддерживается запрошенный тип результирующей картинки, то нужно возвращать 406. Ну, а "ошибка чтения" — это по любому 400 Bad Request.
S> Я надеюсь, то, что упомянутые параметры будут передаваться в хидерах Content-Type и Accept, дополнительно пояснять не нужно?

Отлично я подмастил с медиа-типами Ну да ладно. Усложним задачу. Сервер предъявляет к картинке следующие требования: она не должна быть больше 800x600 и не должна быть монохромной. Какие коды ошибок будут для каждого из этих случаев. И кстати, 400 Bad Request совсем не однозначен. Как знать, может я там с синтаксисом запроса ошибся, а не с форматом параметра

S> H>Я, как и ранее, скажу за XML-RPC. Так вот, клиенту XML-RPC ничто не мешает (и даже вменяется в обязанность) реагировать на статус коды транспорта соответствующим образом.

S> Ну, ещё немного, и мы получим из вашего XML-RPC полноценный REST. Чо уж там — если статус коды стали поддерживать, то надо идти

Стали? Да они поддерживаются изначально

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

H>>Именно так и понимаю.
IB>что-то не похоже, иначе бы к state в определении не примотался.
Не, давайте раскроем карты и поймём, о каком state идёт речь.
С моей точки зрения, настоящие stateless — сервисы в жизни практически не встречаются. Ну, вот по соседству приводился пример "сервиса конверсии картинок" — в нём, вроде бы, state отсутствует, т.к. всё необходимое для конверсии приезжает в самом реквесте.
Интуитивно понятно, что во-первых, это синтетический пример, а во-вторых, такие примеры в реальных приложениях встречаются редко.
Грубо говоря — потому, что в таком случае проще скачать код конвертера картинок локально, и избегать дорогого взаимодействия по сети.

Мой поинт — в том, что в первом приближении stateless-сервисами можно пренебречь, и рассматривать только те сервисы, в которых присутствует некое состояние.

Вопрос — в том, какая модель взаимодействия лучше описывает эти особенности.
Исторически, RPC как концепция появился в попытках изолировать программиста от подробностей распределённой природы приложения, эмулируя знакомые ему термины — вызов, возврат результата, исключение.
При этом основное, что пытается получить RPC — инкапсуляция. Типа, благодаря чернокоробочности сервера мы можем легко подменять реализацию, а также писать клиентов, способных работать с широким набором серверов.

Вопросы надёжности и производительности, неизбежно возникающие из-за распределённости, не поднимаются вообще.
И зря.

Концепция REST состоит в признании того факта, что у нас есть состояние, и оно распределено — т.е. манипуляции этим состоянием дороги и ненадёжны.

Из этой концепции проистекают два основных вывода:
1. Для обеспечения высокой производительности нам важно уметь динамически перераспределять или реплицировать состояние. То есть, вместо обязательного раундтрипа до Самого Главного Сервера мы можем обойтись обращением к посреднику; при этом посредник по-прежнему ничего не знает о подробностях реализации сервера.
2. Для обеспечения надёжности нам нужно уметь выражать намерения в манипуляции состоянием. Не в виде вызова blackbox — процедур, которые непредсказуемым образом меняют состояние, а в виде "я хочу получить вот такое целевое состояние". Принципиальная разница — в том, что мы решаем "проблему двух генералов", хотя и вероятностным способом. Если я получил таймаут, то в случае как RPC, так и REST я не знаю, в каком состоянии оказалась моя система. (Именно это незнание кардинально отличает сетевые приложения от локальных — "дома" у меня гарантирован либо успех, либо исключение, и основное внимание уделяется сохранению инвариантов при вылете исключений). Различия между REST и RPC начинаются при "втором" вызове — в RPC мне страшно делать второй вызов, т.к. его результат зависит от состояния, а я его теперь не знаю. В REST методы манипуляции идемпотентны, поэтому я могу спокойно долбить одно и то же, пока не получу один из двух результатов — "успех" либо "неудача". В обоих случаях целостность распределённого состояния автоматически восстанавливается: моё локальное представление о том, что там сейчас делается на сервере, становится корректным.

А то, что SOAP декларируется как stateless, никакого отношения к надёжности или производительности не имеет.

Здравствуйте, IB, Вы писали:
IB>А спецификация 1.0? Я как бы исхожу из здравого предположения, что "SOAP is fundamentally a stateless, one-way message exchange paradigm...", как гласит нам все та же спецификация.
А её не было никогда. То, что в народе называют "1.0" — это 1.1. Её писала Майкрософт — Дон Бокс и прочие хорошо известные нам люди.
А SOAP 2 — это 1.2, разработанная, вроде бы, w3c (и угробищная, как практически всё из этой шарашки).

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

H>Нет конечно, как и не будет проблем с чрезмерно активно кеширующим прокси. Да-да, не в идеальном мире живем.
Мы — в идеальном. Проблемы от "чрезмерно активных" прокси обычно возникают у тех, кто плохо читает спецификацию и втыкает хидеры от балды.
Зато возможность поднять производительность сервера в десяток раз путём тупого втыкания перед ним nginx или ISA в режиме reverse proxy для RPC отсутствует как класс.

H>Отчего-же опциональных? Внешний интерфейс он есть штука целостная (на то он и интерфейс, контракт т.е.), как спроектировал так и будет.
Оттого опциональных, что я не хочу обязывать клиента быть cache-aware. Я хочу иметь низкий порог вхождения, чтобы конформную реализацию что клиента, что сервера было сделать легко и дёшево.

H>Какие это плюшки мы теряем? У XML-RPC есть интроспекция, вполне себе аналог WSDL. А тулкиты умели генерировать код еще в бородатых девяностых.
С учётом отсутствия стандарта на XML-RPC, я не понимаю о каких тулкитах идёт речь.
Для SOAP наработан огромный стек технологий.

H>Отлично я подмастил с медиа-типами Ну да ладно. Усложним задачу. Сервер предъявляет к картинке следующие требования: она не должна быть больше 800x600 и не должна быть монохромной. Какие коды ошибок будут для каждого из этих случаев. И кстати, 400 Bad Request совсем не однозначен. Как знать, может я там с синтаксисом запроса ошибся, а не с форматом параметра
Заранее предупреждаю: чем сильнее мы будем усложнять задачу, тем сильнее будет сосать RPC.
В данном конкретном примере я спрошу внезапно: а какую логику обработки ошибок вы хотите реализовать в клиенте вашего протокола?

H>Стали? Да они поддерживаются изначально
Беседа становится интересной — давайте поскипаем побочные ветки, и сосредоточимся на примерах, где наглядно увидим всю убогость RPC по сравнению с современными подходами.

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

S> H>Нет конечно, как и не будет проблем с чрезмерно активно кеширующим прокси. Да-да, не в идеальном мире живем.

S> Мы — в идеальном. Проблемы от "чрезмерно активных" прокси обычно возникают у тех, кто плохо читает спецификацию и втыкает хидеры от балды.

Вот потому и не в идеальном. Не так давно пришлось ручками сбрасывать проксёвый кеш для пары сайтов (rutracker.ru, nix.ru), потому как работать перестали начисто (первый не давал скачать торренты + не работал поиск, второй не отображал позиции прайса)

S> Зато возможность поднять производительность сервера в десяток раз путём тупого втыкания перед ним nginx или ISA в режиме reverse proxy для RPC отсутствует как класс.

Вообще-то не отсутствует. Можно реализовать специализированный прокси.

S> H>Отчего-же опциональных? Внешний интерфейс он есть штука целостная (на то он и интерфейс, контракт т.е.), как спроектировал так и будет.

S> Оттого опциональных, что я не хочу обязывать клиента быть cache-aware. Я хочу иметь низкий порог вхождения, чтобы конформную реализацию что клиента, что сервера было сделать легко и дёшево.

У нас есть контракт и всякий решивший его реализовать должен делать это в полной мере. Впрочем, это не лишает возможности клиента дергать методы без опциональных параметров. Даже больше того, реализовать опциональные методы конечно же можно, а клиент может проверять их наличие методами интроспекции (таким как system.listMethods). Правда ни к чему кроме путаницы это не приведет, проще работать с целостным контрактом.

S> С учётом отсутствия стандарта на XML-RPC, я не понимаю о каких тулкитах идёт речь.
S> Для SOAP наработан огромный стек технологий.

У XML-RPC есть официальная спецификация. Так же есть выработанная сообществом спецификация на интерфейс интроспекции. Все нормальные тулкиты её поддерживают.

S> H>Отлично я подмастил с медиа-типами Ну да ладно. Усложним задачу. Сервер предъявляет к картинке следующие требования: она не должна быть больше 800x600 и не должна быть монохромной. Какие коды ошибок будут для каждого из этих случаев. И кстати, 400 Bad Request совсем не однозначен. Как знать, может я там с синтаксисом запроса ошибся, а не с форматом параметра

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

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

S> H>Стали? Да они поддерживаются изначально

S> Беседа становится интересной — давайте поскипаем побочные ветки, и сосредоточимся на примерах, где наглядно увидим всю убогость RPC по сравнению с современными подходами.

Ага, я тебе сразу напомню ветку, где ты предлагал пихать в URI фрагмент мелодии в base64

Здравствуйте, hattab, Вы писали:
H>Вот потому и не в идеальном. Не так давно пришлось ручками сбрасывать проксёвый кеш для пары сайтов (rutracker.ru, nix.ru), потому как работать перестали начисто (первый не давал скачать торренты + не работал поиск, второй не отображал позиции прайса)
А вы уверены, что тут виноват прокси, а не сервер, который, скажем, забыл отдать content-length, из-за чего прокси при обрыве закачки результата с 200 Ok решил, что всё в порядке, и закешировал респонс?
Поймите, что видов прокси-серверов — единицы. Они вылизаны так, как вашему апп-серверу не приснится и во влажном сне.

H>Вообще-то не отсутствует. Можно реализовать специализированный прокси.
Знаете, я буду считать, что отсутствует. Во-первых, реализация "специализированного прокси" удвоит стоимость вашего проекта на ровном месте. Потому что строчек в нём будет примерно столько же, сколько и в вашем основном сервисе.
Во-вторых, вам придётся постоянно заниматься синхронизацией апдейтов — потому что вам придётся аккуратно декорировать каждый метод, и несоответствие версий прокси и аппсервера сломает всю систему. В третьих, сделать так, чтобы ваш "специализированный прокси" не тормозил, а ускорял работу — это ещё одно довольно-таки интересное упражнение. Вы в курсе, как внутри устроен nginx? Уверены, что сможете сделать так же?
В четвёртых, в HTTP проксей может быть сколько угодно. Помимо reverse proxy на серверной стороне, у нас может стоять локальный прокси у кого-то из крупных клиентов, что обеспечивает консолидацию трафика и рост производительности. В вашем случае вы вряд ли продадите ваш "консолидированный прокси" для установки на стороне клиента, особенно с учётом "во-вторых".
В-пятых, один из частоиспользуемых "прокси" — это локальный кэш браузера. Ваше решение гарантирует его неиспользование — а тем временем, его hit ratio может быть очень большим. Так что если мы говорим о веб-приложении, т.е. о коде исполняемом внутри браузера, то XML-RPC мало что может предложить, даже при условии написания этого вашего гипотетического "специализированного прокси".

H>У нас есть контракт и всякий решивший его реализовать должен делать это в полной мере. Впрочем, это не лишает возможности клиента дергать методы без опциональных параметров. Даже больше того, реализовать опциональные методы конечно же можно, а клиент может проверять их наличие методами интроспекции (таким как system.listMethods). Правда ни к чему кроме путаницы это не приведет, проще работать с целостным контрактом.
Это в вашем "неидеальном мире" это не приводит ни к чему, кроме путаницы и навязанных "должен делать это в полной мере".
В идеальном мире REST я могу реализовать сервис вообще без учёта кэширования, анонсировав его наличие у клиентов.
(Кстати, внутрибраузерные клиенты и прокси-сервера автоматически выполняют conditional get при соблюдении простых условий.)
А потом, посмотрев на статистику, могу прикрутить кэширование в конкретных узких местах — с сохранением backward и forward совместимости. И мои клиенты — те, что поумнее, автоматически подхватят эти изменения.
Вы же с вашим XML-RPC вынуждены с самого начала тратить ресурсы на предсказание узких мест и реализацию методов кэширования, которые могут никогда не понадобиться.

H>У XML-RPC есть официальная спецификация. Так же есть выработанная сообществом спецификация на интерфейс интроспекции. Все нормальные тулкиты её поддерживают.
Например? У меня уже есть в Visual Studio кнопочка "заимпортировать определение XML-RPC сервиса", которая создаст мне клиентскую часть соединения, зарегистрирует классы DTO и контракты сервисов?


H>Хотя бы просто внятно объяснить юзеру чем именно серверу не нравится картинка. В протоколах предусматривающих специальный формат сообщения об ошибке это не проблема, т.к. такие сообщения автоматически конвертируются на клиенте в исключительные ситуации.
Отлично. В REST из коробки есть возможность передавать тело сообщения вместе с не-200 статус кодами. Я просто в дополнение к 400 Bad Request отправляю тело, в котором на нужном языке написано, чем именно серверу не нравится картинка.
Клиент показывает это пользователю, все довольны. Никаких специальных форматов сообщения об ошибке, автоматической конвертации на клиенте в исключения, и обратной конвертации в текст тут не надо. Не занимайтесь овердизайном

H>Ага, я тебе сразу напомню ветку, где ты предлагал пихать в URI фрагмент мелодии в base64
И это, кстати, вовсе не такой плохой вариант, как хочется представить. В том смысле, что когда мы начнём предъявлять требования к масштабированию или надёжности, внезапно может оказаться, что это решение выиграет у кондового RPC.
Ну и если будут причины, то можно и обойтись без дружественности к кэшированию и прочих плюшек, не выходя за пределы REST — он же не запрещает делать POST вместо GET. REST просто объясняет, почему это неэффективно.

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

H>Важна-то суть. Объект есть набор данных и объединенных с ними методов обработки. Все. Большего и не нужно. У SOAP в Design goals что написано?
H>

A major design goal for SOAP is simplicity and extensibility. This means that there are several features from traditional messaging systems and distributed object systems that are not part of the core SOAP specification. Such features include
H>Distributed garbage collection
H>Boxcarring or batching of messages
H>Objects-by-reference (which requires distributed garbage collection)
H>Activation (which requires objects-by-reference)

H>Отличная демонстрация наличия stateful механики
Вообще-то это демонстрация техники невнимательного чтения.

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

S> H>Вот потому и не в идеальном. Не так давно пришлось ручками сбрасывать проксёвый кеш для пары сайтов (rutracker.ru, nix.ru), потому как работать перестали начисто (первый не давал скачать торренты + не работал поиск, второй не отображал позиции прайса)

S> А вы уверены, что тут виноват прокси, а не сервер, который, скажем, забыл отдать content-length, из-за чего прокси при обрыве закачки результата с 200 Ok решил, что всё в порядке, и закешировал респонс?

Я не в курсе, кто там был виноват, но факт остается фактом. Проблемы с кешированием это не сказочные мифы, а вполне себе суровая реальность. И хорошо еще если такая проблема очевидна (ломает приложение), а если гадит втихую...

S> Поймите, что видов прокси-серверов — единицы. Они вылизаны так, как вашему апп-серверу не приснится и во влажном сне.

Ну-да, ну-да... И пишут их не люди, а эльфы. Еще пример траблы с кешированием, уже не проксёй. Лично у меня, была проблема с кешированием в IE, когда эта сука единожды получив .cab с активиксом ни в какую не хотела качать его новую версию (несмотря на то, что все условия для обновления выполнялись, в *.inf все было прописано правильно). Мне тогда было совсем не весело.

S> Знаете, я буду считать, что отсутствует. Во-первых, реализация "специализированного прокси" удвоит стоимость вашего проекта на ровном месте. Потому что строчек в нём будет примерно столько же, сколько и в вашем основном сервисе.
S> Во-вторых, вам придётся постоянно заниматься синхронизацией апдейтов — потому что вам придётся аккуратно декорировать каждый метод, и несоответствие версий прокси и аппсервера сломает всю систему. В третьих, сделать так, чтобы ваш "специализированный прокси" не тормозил, а ускорял работу — это ещё одно довольно-таки интересное упражнение. Вы в курсе, как внутри устроен nginx? Уверены, что сможете сделать так же?
S> В четвёртых, в HTTP проксей может быть сколько угодно. Помимо reverse proxy на серверной стороне, у нас может стоять локальный прокси у кого-то из крупных клиентов, что обеспечивает консолидацию трафика и рост производительности. В вашем случае вы вряд ли продадите ваш "консолидированный прокси" для установки на стороне клиента, особенно с учётом "во-вторых".
S> В-пятых, один из частоиспользуемых "прокси" — это локальный кэш браузера. Ваше решение гарантирует его неиспользование — а тем временем, его hit ratio может быть очень большим. Так что если мы говорим о веб-приложении, т.е. о коде исполняемом внутри браузера, то XML-RPC мало что может предложить, даже при условии написания этого вашего гипотетического "специализированного прокси".

А почему мы должны говорить о приложении внутри браузера (Flex морду я внутрибраузерной прилагой не считаю)? У меня таких приложений нет вообще, везде используем десктопных клиентов, и что-то проблем с RPC не отгребали ни разу Специализированный прокси разработать ничуть не сложно, и ни какой синхронизации с сервисом делать не нужно т.к. ему достаточно уметь обрабатывать несколько "специальных" методов, а для остальных работать в режиме моста. И это при условии, что оно вообще когда нибудь понадобится.

S> H>У нас есть контракт и всякий решивший его реализовать должен делать это в полной мере. Впрочем, это не лишает возможности клиента дергать методы без опциональных параметров. Даже больше того, реализовать опциональные методы конечно же можно, а клиент может проверять их наличие методами интроспекции (таким как system.listMethods). Правда ни к чему кроме путаницы это не приведет, проще работать с целостным контрактом.

S> Это в вашем "неидеальном мире" это не приводит ни к чему, кроме путаницы и навязанных "должен делать это в полной мере".
S> В идеальном мире REST я могу реализовать сервис вообще без учёта кэширования, анонсировав его наличие у клиентов.
S> (Кстати, внутрибраузерные клиенты и прокси-сервера автоматически выполняют conditional get при соблюдении простых условий.)
S> А потом, посмотрев на статистику, могу прикрутить кэширование в конкретных узких местах — с сохранением backward и forward совместимости. И мои клиенты — те, что поумнее, автоматически подхватят эти изменения.
S> Вы же с вашим XML-RPC вынуждены с самого начала тратить ресурсы на предсказание узких мест и реализацию методов кэширования, которые могут никогда не понадобиться.

Ну да, мы прежде предпочитаем проектировать, а потом уже код писать

S> H>У XML-RPC есть официальная спецификация. Так же есть выработанная сообществом спецификация на интерфейс интроспекции. Все нормальные тулкиты её поддерживают.

S> Например? У меня уже есть в Visual Studio кнопочка "заимпортировать определение XML-RPC сервиса", которая создаст мне клиентскую часть соединения, зарегистрирует классы DTO и контракты сервисов?

Не знаю на счет студии (хотя для дотнета есть неплохая библиотека xml-rpc.net с генерацией прокси-классов для xml-rpc сервисов), но, например, сишный тулкит xml-rpc.c имеет утиль для формирования с-апи по сигнатурам xml-rpc методов.

S> H>Хотя бы просто внятно объяснить юзеру чем именно серверу не нравится картинка. В протоколах предусматривающих специальный формат сообщения об ошибке это не проблема, т.к. такие сообщения автоматически конвертируются на клиенте в исключительные ситуации.

S> Отлично. В REST из коробки есть возможность передавать тело сообщения вместе с не-200 статус кодами. Я просто в дополнение к 400 Bad Request отправляю тело, в котором на нужном языке написано, чем именно серверу не нравится картинка.
S> Клиент показывает это пользователю, все довольны. Никаких специальных форматов сообщения об ошибке, автоматической конвертации на клиенте в исключения, и обратной конвертации в текст тут не надо. Не занимайтесь овердизайном

Но если на ошибку нужно реагировать приложению... то как я и говорил

Автор: hattab
Дата: 17.01.13

, задача сообщить подробную ошибку приводит к велосипеду.

S> H>Ага, я тебе сразу напомню ветку, где ты предлагал пихать в URI фрагмент мелодии в base64

S> И это, кстати, вовсе не такой плохой вариант, как хочется представить. В том смысле, что когда мы начнём предъявлять требования к масштабированию или надёжности, внезапно может оказаться, что это решение выиграет у кондового RPC.
S> Ну и если будут причины, то можно и обойтись без дружественности к кэшированию и прочих плюшек, не выходя за пределы REST — он же не запрещает делать POST вместо GET. REST просто объясняет, почему это неэффективно.

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

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

S> Вообще-то это демонстрация техники невнимательного чтения.

Посыпался пеплом

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

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

H>Еще пример траблы с кешированием, уже не проксёй. Лично у меня, была проблема с кешированием в IE, когда эта сука единожды получив .cab с активиксом ни в какую не хотела качать его новую версию (несмотря на то, что все условия для обновления выполнялись, в *.inf все было прописано правильно). Мне тогда было совсем не весело.
При чём тут .inf? Какие хидеры были отданы с этим .cab?

H>А почему мы должны говорить о приложении внутри браузера (Flex морду я внутрибраузерной прилагой не считаю)?
Например потому, что есть большой рынок таких приложений. Невозможность потреблять сервис из тонкого клиента — этот вовсе не преимущество. Кроме того, "внутрибраузерный кэш" — это не только IE, но и весь WinInet. То есть ваш десктопный клиент может воспользоваться преимуществами HTTP кэширования прозрачно для вас и забесплатно.

H>Специализированный прокси разработать ничуть не сложно, и ни какой синхронизации с сервисом делать не нужно т.к. ему достаточно уметь обрабатывать несколько "специальных" методов, а для остальных работать в режиме моста. И это при условии, что оно вообще когда нибудь понадобится.
У вас есть реальный опыт разработки специализированного прокси для XML-RPC или JSON-RPC?

H>Ну да, мы прежде предпочитаем проектировать, а потом уже код писать
И сколько раз вы успели реально спроектировать в ваших многочисленных XML-RPC реализациях поддержку кэширования?

H>Но если на ошибку нужно реагировать приложению... то как я и говорил

Автор: hattab
Дата: 17.01.13

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

H>Ну да, не плохой, если забить на ограничения дефолтных реализаций
Какие именно ограничения дефолтных реализаций вы имеете в виду?
H>Да и о кэшировании, в даном случае, говорить довольно странно т.к. вероятность получить идентичный URI если не нулевая, то стремящаяся к нему.
В данном случае — да. Поэтому можно и не стремиться упаковать всё в URL и пользоваться Get-ом. Можно и сделать POST, с тем же примерно успехом. Ну, только разве что в отличие от XML-RPC можно передавать данные в теле бинарно, а не енкодить в base64.


H>Касаемо масштабируемости. Когда говорят о масштабируемости, почему-то считается, что RPC обрабатывается одним узлом. Вот с чего бы вдруг
С того бы вдруг, что во всех RPC реализациях URL у ендпоинта ровно один, и его hostname резолвится в фиксированный список IP адресов. Поэтому RPC-сервер неспособен управлять балансировкой; для масштабирования вам придётся поставить перед ним Load Balancer, а это недёшево и всё ещё имеет ограничения по масштабу. REST работает с пространством URL, которые вовсе не обязаны сидеть за одним и тем же hostname, поэтому со стороны сервера я могу балансировать нагрузку так, как мне удобно. Ваш К.О.

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

S> О, ну давайте теперь откажемся от кэширования потому, что не понимаем, как оно работает.

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

S> H>Ну-да, ну-да... И пишут их не люди, а эльфы.

S> При чём тут эльфы? Речь о том, что у любого из топовых прокси-серверов как минимум сотни тысяч инсталляций. А у вашего самописанного — одна. Если вам не очевидно, как это влияет на тестовое покрытие, то я даже не знаю, что сказать.

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

S> H>Еще пример траблы с кешированием, уже не проксёй. Лично у меня, была проблема с кешированием в IE, когда эта сука единожды получив .cab с активиксом ни в какую не хотела качать его новую версию (несмотря на то, что все условия для обновления выполнялись, в *.inf все было прописано правильно). Мне тогда было совсем не весело.

S> При чём тут .inf? Какие хидеры были отданы с этим .cab?

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

S> H>А почему мы должны говорить о приложении внутри браузера (Flex морду я внутрибраузерной прилагой не считаю)?

S> Например потому, что есть большой рынок таких приложений. Невозможность потреблять сервис из тонкого клиента — этот вовсе не преимущество. Кроме того, "внутрибраузерный кэш" — это не только IE, но и весь WinInet. То есть ваш десктопный клиент может воспользоваться преимуществами HTTP кэширования прозрачно для вас и забесплатно.

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

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

S> У вас есть реальный опыт разработки специализированного прокси для XML-RPC или JSON-RPC?

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

S> H>Ну да, мы прежде предпочитаем проектировать, а потом уже код писать

S> И сколько раз вы успели реально спроектировать в ваших многочисленных XML-RPC реализациях поддержку кэширования?

У нас такие приложения, что кэширование практически неприменимо Но это не отрицает возможности его реализации в RPC.

S> H>Но если на ошибку нужно реагировать приложению... то как я и говорил

Автор: hattab
Дата: 17.01.13

, задача сообщить подробную ошибку приводит к велосипеду.

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

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

S> H>Ну да, не плохой, если забить на ограничения дефолтных реализаций

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

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

S> H>Да и о кэшировании, в даном случае, говорить довольно странно т.к. вероятность получить идентичный URI если не нулевая, то стремящаяся к нему.

S> В данном случае — да. Поэтому можно и не стремиться упаковать всё в URL и пользоваться Get-ом. Можно и сделать POST, с тем же примерно успехом. Ну, только разве что в отличие от XML-RPC можно передавать данные в теле бинарно, а не енкодить в base64.

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

S> H>Касаемо масштабируемости. Когда говорят о масштабируемости, почему-то считается, что RPC обрабатывается одним узлом. Вот с чего бы вдруг

S> С того бы вдруг, что во всех RPC реализациях URL у ендпоинта ровно один, и его hostname резолвится в фиксированный список IP адресов. Поэтому RPC-сервер неспособен управлять балансировкой; для масштабирования вам придётся поставить перед ним Load Balancer, а это недёшево и всё ещё имеет ограничения по масштабу. REST работает с пространством URL, которые вовсе не обязаны сидеть за одним и тем же hostname, поэтому со стороны сервера я могу балансировать нагрузку так, как мне удобно. Ваш К.О.

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