Comments 122
Даже и прокомментировать нечего — спасибо, понятно.
По поводу последнего абзаца — неужели до сих пор нет «стандартных» протоколов для прямых сокетов? Все на великах?
По поводу последнего абзаца — неужели до сих пор нет «стандартных» протоколов для прямых сокетов? Все на великах?
А как их можно стандартизировать? Если продолжать мой пример, то одна игрушка — это ферма, у нее один список операций, другая — это гонки, ей совешенно другие данные нужны с сервиса. Вот и нужно каждый раз выдумывать — что если первый байт «1» — то вышли список соперников, если «2» — вышли список трасс и т.д.
А удобные классы для работы с сокетами в .Net есть.
А удобные классы для работы с сокетами в .Net есть.
C помощью «прямых сокетов» можно передавать любые данные, например xml или json. Также есть «стандратные» бинарные форматы например BSON. «Велики» в основном нужны чтобы минимизировать трафик, защитить передаваемые данные и т.п.
В WCF есть возможность использования net.tcp биндинга, который базируется на tcp.
простите, под «протоколом» я понимал «формат»
netTcpBinding можно использвать только в .Net.
«TCP/NamedPipe are not meant to be interoperable; they're optimized for WCF-WCF»
social.msdn.microsoft.com/forums/en-US/wcf/thread/2dd96345-e822-4922-83f6-3a875613ee49/
А вообще ведь действительно это возможно стандартизировать, я об этом сначала даже и не подумал.
«TCP/NamedPipe are not meant to be interoperable; they're optimized for WCF-WCF»
social.msdn.microsoft.com/forums/en-US/wcf/thread/2dd96345-e822-4922-83f6-3a875613ee49/
А вообще ведь действительно это возможно стандартизировать, я об этом сначала даже и не подумал.
1. REST не протокол, а архитектура.
2. SOAP — всего лишь один из протоколов реализующих WS-* и отношение у них противоположное указанному вами.
3. SOAP распространен КРАЙНЕ широко в разнообразных энтерпрайз-системах.
4. Ни REST ни SOAP не имеет прямого отношения к RPC, но RPC можно собрать на их базе.
2. SOAP — всего лишь один из протоколов реализующих WS-* и отношение у них противоположное указанному вами.
3. SOAP распространен КРАЙНЕ широко в разнообразных энтерпрайз-системах.
4. Ни REST ни SOAP не имеет прямого отношения к RPC, но RPC можно собрать на их базе.
5. Возможность «расставить галочки» зависит не от SOAP, а от реализации (такой как WCF, который поддерживает далеко не только SOAP, но и даже REST и даже с возможностью генерировать proxy, см. WCF Data Services, например).
1. Да
2. А какие еще есть?
3. Согласен.
4. Не согласен. SOAP реализует идею RPC. ru.wikipedia.org/wiki/Remote_Procedure_Call
5. SOAP (а именно WSDL) позволяет WCF и другим технологиям генерить прокси. REST не позволяет этого сделать. Вот что я хотел сказать. WCF Data Services посмотрю.
2. А какие еще есть?
3. Согласен.
4. Не согласен. SOAP реализует идею RPC. ru.wikipedia.org/wiki/Remote_Procedure_Call
5. SOAP (а именно WSDL) позволяет WCF и другим технологиям генерить прокси. REST не позволяет этого сделать. Вот что я хотел сказать. WCF Data Services посмотрю.
2. MTOM, MSMQ, AMQP, еще что-то было.
4. Почитал подробнее. Да, начался он с RPC, но на данный момент он сильно шире.
5. Неправильно. WSDL описывает Web-сервисы вообще, а не только SOAP(который вообще отвечает только за Messaging), а WSDL 2.0 умеет описывать и REST.
4. Почитал подробнее. Да, начался он с RPC, но на данный момент он сильно шире.
5. Неправильно. WSDL описывает Web-сервисы вообще, а не только SOAP(который вообще отвечает только за Messaging), а WSDL 2.0 умеет описывать и REST.
2. xmpp еще прикручивается без проблем, как и многое другое на самом деле.
В php есть средства для работы с SOAP.
Все по делу, хотя сегодня в мире Java и .NET многие тоже от SOAP отказываются. Сгенерировать REST-клиента на WCF тоже можно, а на стороне Java (которая REST-сервисом оказывается чаще, чем клиентом), есть JAX-RS API, которое в целом проще для понимания и для реализации, чем JAX-WS (последний считает, что вебсервис должен представлять собой EJB).
Много лет назад, в далеком 2007, когда вручную собирал WSDL, и по нему делал сервис и клиент на JAX-RPC, мечтал о том дне, когда банк перейдет наконец-таки с Java 1.3 хотя бы на Java 1.5, и можно будет описывать все аннотациями JAX-WS.
И вот прошло время, и сегодня я с ужасом думаю, что может понадобиться работать с SOAP.
Много лет назад, в далеком 2007, когда вручную собирал WSDL, и по нему делал сервис и клиент на JAX-RPC, мечтал о том дне, когда банк перейдет наконец-таки с Java 1.3 хотя бы на Java 1.5, и можно будет описывать все аннотациями JAX-WS.
И вот прошло время, и сегодня я с ужасом думаю, что может понадобиться работать с SOAP.
А почему сейчас боитесь работать с SOAP на JAVA? ) вроде бы сейчас уже нормальная его поддержка есть
«Сгенерировать REST-клиента на WCF тоже можно». Как? Самое лучшее, что я нашел — это WCF REST starter kit, который был написан под .Net framework 3.5, в 4 уже были внедрены некоторые его фичи, а в 4.5 фреймверк, я так понял, он будет полностью встроен.
В этом WCF REST starter kit есть удобные фичи, но это все же не полноценная генерация прокси.
«Сгенерировать REST-клиента на WCF тоже можно». Как? Самое лучшее, что я нашел — это WCF REST starter kit, который был написан под .Net framework 3.5, в 4 уже были внедрены некоторые его фичи, а в 4.5 фреймверк, я так понял, он будет полностью встроен.
В этом WCF REST starter kit есть удобные фичи, но это все же не полноценная генерация прокси.
Мне казалось flex разработчики прредпочитают BlazeDS.
Ruby совсем не поддерживает SOAP? А Savon.rb?
Или soap4r
UFO just landed and posted this here
Почувствуйте разницу 2
Каждый раз читая сравнения rest vs webservice мне хочется спросить у автора — у вас любая модель взаимодействия укладывается в REST модель? Задача WSDL это не положить/забрать/удалить ресурс — а надежная и удобная организация распределенных гетерогенных приложений.
В теории я с Вами согласен. На практике — нет.
Можете придумать конкретную задачу, с которой RESTful сервис бы не справился?
Можете придумать конкретную задачу, с которой RESTful сервис бы не справился?
согласен с kivsiak.
С точки зрения теории можно любую задачу раскидать на объекты.
Объекты нужно создавать, задавать им параметры, получать их данные.
Далее объекты = ресурсы. и тогда к ним можно применять идеологию REST.
Получается достаточно красиво. А теперь пример задачи на вскидку.
Есть сервис, которого можно попросить удаленно что-нибудь сделать.
Пусть он всё делает в фоне.
схема общения такая, создаем задачу, запоминаем её ID.
Ждем, спрашиваем не готово ли. (можно и не ждать, а ожидать какого-либо события, переданного как-то, но не в этом суть, пусть для простоты будет так)
Получаем по ID результат.
Казалось бы, очень красиво всё ложится в REST.
Пишем ресурс задачи. Создание её, получение данных и т.п.
Дошли до клиента. выходит — нужно писать логику, сформировать XML(JSON), отослать, получить назад XML(JSON) обработать.
сформировать урл для получения данных для задачи. опять послать запрос, получить результат распарсить.
Если пишем на Java, то можно красиво смапить XML в объекты(хотя и). На других языках получается всё менее красиво, слишком много телодвижений.
Главный для меня минус, если структура сообщений поменяется (или мы в ней сделали ошибку), мы 100 лет будет искать ошибку. Как проверять скопировались данные или нет — тоже не понятно. Лучший способ, покрыть обильно данный код тестами. в итоге получается такая жирненькая задачка.
Пишем аналог на SOAP. Описываем сервис, он должен обмениваться объектами. Создаем задачу вызовом одного метода. получаем результат вызовом другого метода. Если результат получен — сразу у нас в программе объект с данными(если язык это поддерживает).
никаких XML, никакого парсинга. Нужно добиться чтобы версии SOAP совпадали и клиенты их правильно поддерживали.
Трудоемкость такой задачи на порядок меньше. Плюс контроль данных, которые приходят.
Итог, задача красиво ложится на REST архитектуру, а в SOAP её проще и быстрее реализовать по трудоемкости. Т.к. SOAP берет часть работы по валидации данных на себя. За счет этого оно и проще.
Проблему частично решает WADL. Но, генераторы кода клиента есть только на Java.
Итог для меня, простые вещи без какой-то особой логики можно реализовывать на REST.
Клиент пишется в 2 строчки, особой валидации не нужно и т.п.
Когда система усложняется, то нужно уже думать — как оно лучше, удобней и проще реализовать.
С точки зрения теории можно любую задачу раскидать на объекты.
Объекты нужно создавать, задавать им параметры, получать их данные.
Далее объекты = ресурсы. и тогда к ним можно применять идеологию REST.
Получается достаточно красиво. А теперь пример задачи на вскидку.
Есть сервис, которого можно попросить удаленно что-нибудь сделать.
Пусть он всё делает в фоне.
схема общения такая, создаем задачу, запоминаем её ID.
Ждем, спрашиваем не готово ли. (можно и не ждать, а ожидать какого-либо события, переданного как-то, но не в этом суть, пусть для простоты будет так)
Получаем по ID результат.
Казалось бы, очень красиво всё ложится в REST.
Пишем ресурс задачи. Создание её, получение данных и т.п.
Дошли до клиента. выходит — нужно писать логику, сформировать XML(JSON), отослать, получить назад XML(JSON) обработать.
сформировать урл для получения данных для задачи. опять послать запрос, получить результат распарсить.
Если пишем на Java, то можно красиво смапить XML в объекты(хотя и). На других языках получается всё менее красиво, слишком много телодвижений.
Главный для меня минус, если структура сообщений поменяется (или мы в ней сделали ошибку), мы 100 лет будет искать ошибку. Как проверять скопировались данные или нет — тоже не понятно. Лучший способ, покрыть обильно данный код тестами. в итоге получается такая жирненькая задачка.
Пишем аналог на SOAP. Описываем сервис, он должен обмениваться объектами. Создаем задачу вызовом одного метода. получаем результат вызовом другого метода. Если результат получен — сразу у нас в программе объект с данными(если язык это поддерживает).
никаких XML, никакого парсинга. Нужно добиться чтобы версии SOAP совпадали и клиенты их правильно поддерживали.
Трудоемкость такой задачи на порядок меньше. Плюс контроль данных, которые приходят.
Итог, задача красиво ложится на REST архитектуру, а в SOAP её проще и быстрее реализовать по трудоемкости. Т.к. SOAP берет часть работы по валидации данных на себя. За счет этого оно и проще.
Проблему частично решает WADL. Но, генераторы кода клиента есть только на Java.
Итог для меня, простые вещи без какой-то особой логики можно реализовывать на REST.
Клиент пишется в 2 строчки, особой валидации не нужно и т.п.
Когда система усложняется, то нужно уже думать — как оно лучше, удобней и проще реализовать.
> если структура сообщений поменяется (или мы в ней сделали ошибку), мы 100 лет будет искать ошибку
Не будете. Версионность для REST-сервисо тоже никто не отменял
Не будете. Версионность для REST-сервисо тоже никто не отменял
если я правильно понял, что такое версионность, то с SOAP конечно легче — он сам найдет все изменеия структуры сообщений и внесет поправки. С REST все вручную
> то с SOAP конечно легче — он сам найдет все изменеия структуры сообщений и внесет поправки.
С какого перепугу он найдет это сам? И что мешает сделать такое же для REST?
С какого перепугу он найдет это сам? И что мешает сделать такое же для REST?
>>С какого перепугу он найдет это сам? И что мешает сделать такое же для REST?
если формат данных будет не такой, как WSDL, то обмен данными просто не будет работать. Это и называется, он сам найдет.
Для REST такое тоже есть WADL, но проблема в том, что многие разработчики считают, что он не укладывается в архитектуру REST и потому он не нужен.
А кому-то просто лень реализовывать генерацию ещё одной XML, которая только всё усложняет.
если формат данных будет не такой, как WSDL, то обмен данными просто не будет работать. Это и называется, он сам найдет.
Для REST такое тоже есть WADL, но проблема в том, что многие разработчики считают, что он не укладывается в архитектуру REST и потому он не нужен.
А кому-то просто лень реализовывать генерацию ещё одной XML, которая только всё усложняет.
>>Не будете. Версионность для REST-сервисо тоже никто не отменял
Буду, но не там, где вы думаете.
простите, похоже вы не так поняли то, что я имел в виду.
Я не за, и не против REST. Более того, в предпоследнем проекте делал обмен на REST, в последнем на SOAP. Поэтому у меня сложилось свое мнение относительно этих двух идей реализаций обмена данными.
Вариант первый. Вы пишите сервер, клиенты пишут все остальные. Главное, не вы. К тому же, клиентов туча и они разношерстные (разные языки, платформы и т.п.).
Тут я думаю лучше использовать REST. Плюс в том, что отдаются данные в каком-нибудь стандартном формате. Например, XML. Добавляем сюда весь богатый инструментарий по валидации этих данных — и всё в шоколаде. Главное вы отдаете данные правильно. Остальное вас не касается. Пример, Twitter и тому подобное.
Тут нареканий нет, очень удобная и гибкая архитектура.
SOAP же в этом случае применять не очень удобно, т.к. будет много накладных проблем с разными версиями SOAP а так же с особенностями реализации клиента SOAP на каждой из платформ.
Вариант второй, и клиент, и сервер ваши. Вам нужно передать объект А от сервера к клиенту или наоборот. В этом случае SOAP дает решение из коробки. Поднимаем сервер, описываем объект и у нас всё работает.
А теперь про ошибку, если я беру данные с какого-либо REST-сервиса, то по-хорошему нужно проверять, а правильно ли я их беру. Эту проверку осуществляет клиент, а не сервер.
Для REST вам придется писать её руками, или не писать, но при этом придется больше внимания уделить тестированию (никто не даст гарантии, что при очередном рефакторинге у вас чего-нибудь не отвалится).
Буду, но не там, где вы думаете.
простите, похоже вы не так поняли то, что я имел в виду.
Я не за, и не против REST. Более того, в предпоследнем проекте делал обмен на REST, в последнем на SOAP. Поэтому у меня сложилось свое мнение относительно этих двух идей реализаций обмена данными.
Вариант первый. Вы пишите сервер, клиенты пишут все остальные. Главное, не вы. К тому же, клиентов туча и они разношерстные (разные языки, платформы и т.п.).
Тут я думаю лучше использовать REST. Плюс в том, что отдаются данные в каком-нибудь стандартном формате. Например, XML. Добавляем сюда весь богатый инструментарий по валидации этих данных — и всё в шоколаде. Главное вы отдаете данные правильно. Остальное вас не касается. Пример, Twitter и тому подобное.
Тут нареканий нет, очень удобная и гибкая архитектура.
SOAP же в этом случае применять не очень удобно, т.к. будет много накладных проблем с разными версиями SOAP а так же с особенностями реализации клиента SOAP на каждой из платформ.
Вариант второй, и клиент, и сервер ваши. Вам нужно передать объект А от сервера к клиенту или наоборот. В этом случае SOAP дает решение из коробки. Поднимаем сервер, описываем объект и у нас всё работает.
А теперь про ошибку, если я беру данные с какого-либо REST-сервиса, то по-хорошему нужно проверять, а правильно ли я их беру. Эту проверку осуществляет клиент, а не сервер.
Для REST вам придется писать её руками, или не писать, но при этом придется больше внимания уделить тестированию (никто не даст гарантии, что при очередном рефакторинге у вас чего-нибудь не отвалится).
> >>Не будете. Версионность для REST-сервисо тоже никто не отменял
> Буду, но не там, где вы думаете.
> простите, похоже вы не так поняли то, что я имел в виду.
Объяснения к этому: «если структура сообщений поменяется (или мы в ней сделали ошибку), мы 100 лет будет искать ошибку» так и не было ;)
> Вам нужно передать объект А от сервера к клиенту или наоборот. В этом случае SOAP дает решение из коробки. Поднимаем сервер, описываем объект и у нас всё работает.
Только в случае, если в будущем нам не пондобится отдавать этот сервис наружу.
> если я беру данные с какого-либо REST-сервиса, то по-хорошему нужно проверять, а правильно ли я их беру. Эту проверку осуществляет клиент, а не сервер.
Открою страшную тайну: данные надо проверять ВСЕГДА, даже если мы берем их по SOAP'у.
> Для REST вам придется писать её руками,
это противоречит вышеописанному: « Плюс в том, что отдаются данные в каком-нибудь стандартном формате. Например, XML. Добавляем сюда весь богатый инструментарий по валидации этих данных — и всё в шоколаде. Главное вы отдаете данные правильно.»
> никто не даст гарантии, что при очередном рефакторинге у вас чего-нибудь не отвалится
А почему оно должно отвалиться, и почему оно не отвалится при неREST'е?
> Буду, но не там, где вы думаете.
> простите, похоже вы не так поняли то, что я имел в виду.
Объяснения к этому: «если структура сообщений поменяется (или мы в ней сделали ошибку), мы 100 лет будет искать ошибку» так и не было ;)
> Вам нужно передать объект А от сервера к клиенту или наоборот. В этом случае SOAP дает решение из коробки. Поднимаем сервер, описываем объект и у нас всё работает.
Только в случае, если в будущем нам не пондобится отдавать этот сервис наружу.
> если я беру данные с какого-либо REST-сервиса, то по-хорошему нужно проверять, а правильно ли я их беру. Эту проверку осуществляет клиент, а не сервер.
Открою страшную тайну: данные надо проверять ВСЕГДА, даже если мы берем их по SOAP'у.
> Для REST вам придется писать её руками,
это противоречит вышеописанному: « Плюс в том, что отдаются данные в каком-нибудь стандартном формате. Например, XML. Добавляем сюда весь богатый инструментарий по валидации этих данных — и всё в шоколаде. Главное вы отдаете данные правильно.»
> никто не даст гарантии, что при очередном рефакторинге у вас чего-нибудь не отвалится
А почему оно должно отвалиться, и почему оно не отвалится при неREST'е?
Объяснения к этому: «если структура сообщений поменяется (или мы в ней сделали ошибку), мы 100 лет будет искать ошибку» так и не было ;)
было. Возможно немного невнятно.
Вот оно
А теперь про ошибку, если я беру данные с какого-либо REST-сервиса, то по-хорошему нужно проверять, а правильно ли я их беру. Эту проверку осуществляет клиент, а не сервер.
Для REST вам придется писать её руками, или не писать, но при этом придется больше внимания уделить тестированию (никто не даст гарантии, что при очередном рефакторинге у вас чего-нибудь не отвалится)
поясняю чуть по подробней:
Допустим у нас клиент, который читает данные с REST сервиса.
Допустим вы в парсере допустили ошибку. тег не так назвали. поставили лишнюю букву или пропустили. Или перепутали два тега в процессе разработки копипастом. Итог, данные в объекте либо пустые, либо не те.
Если пустые, то бывает иногда что-нибудь отвалится, а если не те — то это вообще сложно ловить. Я такие вещи ловил юнит тестами, если этого нет, то такой косяк можно поймать:
— внимательными глазами разработчика, который делает вам Code Review (или вы сами проверяли, увидели, так тоже бывает).
— внимательными глазами тестера, который будет сравнивать вход-выход
А может случиться так, что никогда не поймаете. Всплывает уже в процессе эксплуатации через какое-то время.
В контексте вашего же
это возражение непонятно. Что мешает использовать тот же инструментарий для валидации данных на клиенте?
Плюс в том, что отдаются данные в каком-нибудь стандартном формате. Например, XML. Добавляем сюда весь богатый инструментарий по валидации этих данных — и всё в шоколаде.
это возражение непонятно. Что мешает использовать тот же инструментарий для валидации данных на клиенте?
Там фраза вырванная из контекста. Речь шла о другом. о том, что данные в стандартном формате, а значит их можно легко обрабатывать. В шоколаде значит, что подход реально удобен по сравнению с SOAP, если ты публикуешь сервис наружу.
А далее, я говорю, что при обработке могут быть допущены ошибки, этот момент нужно тоже не упустить.
Лично я не считаю, что SOAP хорош для публикации наружу. Бывают проблемы с разными клиентами. Так что для каждой задачи свое.
А далее, я говорю, что при обработке могут быть допущены ошибки, этот момент нужно тоже не упустить.
Лично я не считаю, что SOAP хорош для публикации наружу. Бывают проблемы с разными клиентами. Так что для каждой задачи свое.
Объединю два комментария в один
> данные в стандартном формате, а значит их можно легко обрабатывать.
> А далее, я говорю, что при обработке могут быть допущены ошибки, этот момент нужно тоже не упустить.
В случае с SOAP мы имеем тут же XML и абсолютно те же средства, цитирую:
Что мешает к этим анным применять те же инструменты, что и к SOAP, например? Как на сервере, так и на клиенте?
Почему в «стандартном XML, к которому применяются тулзы по валидации», отправляемом REST'ом, могут появляться трудновылавливаемые ошибки, а в абсолютно таком же «стандартном XML», но который SOAP, эти ошибки появляться не могут?
> данные в стандартном формате, а значит их можно легко обрабатывать.
> А далее, я говорю, что при обработке могут быть допущены ошибки, этот момент нужно тоже не упустить.
В случае с SOAP мы имеем тут же XML и абсолютно те же средства, цитирую:
отдаются данные в каком-нибудь стандартном формате. Например, XML. Добавляем сюда весь богатый инструментарий по валидации этих данных — и всё в шоколаде.
Что мешает к этим анным применять те же инструменты, что и к SOAP, например? Как на сервере, так и на клиенте?
Почему в «стандартном XML, к которому применяются тулзы по валидации», отправляемом REST'ом, могут появляться трудновылавливаемые ошибки, а в абсолютно таком же «стандартном XML», но который SOAP, эти ошибки появляться не могут?
REST — гибкость. структуру документа мы пишем сами. валидаторы пишем сами. парсеры пишем сами. Генерацию XML тоже пишем сами. Сервер тоже пишем сами (роутинг запросов по HTTP, обработка параметров и т.п.).
В каждом языке правда есть средства, которые этот процесс частично упрощают. Но итог, остается один. мы дофига всего пишем сами. А то, что мы пишем сами, нужно проверять.
SOAP — это жесткий протокол. На него написаны уже валидаторы. Написаны схемы данных. Написаны клиенты и сервера.
мы просто описываем объект который хотим послать и канал(фактически запрос, или если хотите функция с параметрами и возвращаемым типом), по которому будем слать.
Параметры и возвращаемый тип — это объекты, которые по косточкам разбираются на элементарные типы.
Итог, мы описываем только структуру данных как объект или группу объектов, остальная работа делается за нас и отдается на откуп клиенту и серверу SOAP.
Делать какие-то ещё проверки бессмыслено, т.к. они уже сделаны. достаточно проверить, что данные пришли те и всё.
Ошибки и в клиенте-сервере SOAP могут быть. Но это ошибки сторонней библиотеки. Про них можно написать в баг репорт. Или вообще уйти на другую библиотеку.
А поскольку этим софтом много кто пользуется, то % ошибок там существенно меньше, чем в вашем коде. В любом случае, вы за него не отвечаете.
В каждом языке правда есть средства, которые этот процесс частично упрощают. Но итог, остается один. мы дофига всего пишем сами. А то, что мы пишем сами, нужно проверять.
SOAP — это жесткий протокол. На него написаны уже валидаторы. Написаны схемы данных. Написаны клиенты и сервера.
мы просто описываем объект который хотим послать и канал(фактически запрос, или если хотите функция с параметрами и возвращаемым типом), по которому будем слать.
Параметры и возвращаемый тип — это объекты, которые по косточкам разбираются на элементарные типы.
Итог, мы описываем только структуру данных как объект или группу объектов, остальная работа делается за нас и отдается на откуп клиенту и серверу SOAP.
Делать какие-то ещё проверки бессмыслено, т.к. они уже сделаны. достаточно проверить, что данные пришли те и всё.
Ошибки и в клиенте-сервере SOAP могут быть. Но это ошибки сторонней библиотеки. Про них можно написать в баг репорт. Или вообще уйти на другую библиотеку.
А поскольку этим софтом много кто пользуется, то % ошибок там существенно меньше, чем в вашем коде. В любом случае, вы за него не отвечаете.
Писать надо не так уж и много. Не намного больше, чем для SOAP. Потому что SOAP не превращается магическим образом в бизнес объекты, например.
> Ошибки и в клиенте-сервере SOAP могут быть. Но это ошибки сторонней библиотеки. Про них можно написать в баг репорт. Или вообще уйти на другую библиотеку.
> А поскольку этим софтом много кто пользуется, то % ошибок там существенно меньше, чем в вашем коде.
Ой да ну :)
Это в какой-то мере справедливо только для структуры ответа, но никак не для самих данных. Вот даю сразу классический пример:
В Швеции каждому резиденту дают уникальный персональный номер, который выглядит как YYYYMMDD-XXXX (длинная версия) или YYMMDD-XXXX (короткая версия).
В подавляющем большинстве случаев используется мало того, что коротка версия, так еще без дефиса посередине.
Итак, имеем:
— поле pno (personal number), тип: s:string
— валидатор данных: проверяем [0-9\-]
На тысячном клиенте структура данных меняется, не меняя при этом структуру ответа. То есть вместо YYMMDDXXXX мы начинаем отсылать YYYYMMDD-XXXX
Тут не спасет ни SOAP ни REST. Причем именно таких ошибок гораздо больше, чем ошибок из-за изменения структуры. При том, что структура, в принципе, обычно генерируется чем-то автоматическим.
> Ошибки и в клиенте-сервере SOAP могут быть. Но это ошибки сторонней библиотеки. Про них можно написать в баг репорт. Или вообще уйти на другую библиотеку.
> А поскольку этим софтом много кто пользуется, то % ошибок там существенно меньше, чем в вашем коде.
Ой да ну :)
Это в какой-то мере справедливо только для структуры ответа, но никак не для самих данных. Вот даю сразу классический пример:
В Швеции каждому резиденту дают уникальный персональный номер, который выглядит как YYYYMMDD-XXXX (длинная версия) или YYMMDD-XXXX (короткая версия).
В подавляющем большинстве случаев используется мало того, что коротка версия, так еще без дефиса посередине.
Итак, имеем:
— поле pno (personal number), тип: s:string
— валидатор данных: проверяем [0-9\-]
На тысячном клиенте структура данных меняется, не меняя при этом структуру ответа. То есть вместо YYMMDDXXXX мы начинаем отсылать YYYYMMDD-XXXX
Тут не спасет ни SOAP ни REST. Причем именно таких ошибок гораздо больше, чем ошибок из-за изменения структуры. При том, что структура, в принципе, обычно генерируется чем-то автоматическим.
Такие вещи нужно проверять в логике объектов там, где это важно. К обмену данными они особого отношения не имеют.
Объекты, которые мы передаем, могут быть и бизнес объектами, или их производными (объекты, которые содержат лишь часть данных бизнес объекта, нужных для передачи).
У меня чаще всего получались производные, а у объекта бизнес логики были методы типа setSubObjectData и getSubObjectData
И ещё раз повторюсь, речь идет о том, чтобы снизить трудоемкость.
Если проект не очень большой, и не очень сложный, то быстрее будет сделать на чем-нибудь готовом. Тот же SOAP в java делается в пару аннотаций в классе для jdk6.
В том же EJB последних версиях тоже есть возможность делать контейнеры-вебсервисы в одну строчку.
Что лучше, написать кучу мапперов, роутеров урлов. и прочее… Ведь их же писать нужно. Что лучше 1 строка или 300 строк? Что будет быстрее разработать? Где будет меньше ошибок?
Если нет каких либо сложных проблем использованием SOAP, то такой путь чуть быстрее. Можно сократить время разработки-отладки.
Велосипеды нынче не в почете, а ещё они могут ломаться.
А начальство ох как этого не любит, при каждой поломке начинает ныть, мол нужно было использовать стандартную или такую-то чужую. Вот приходится взвешивать что лучше чужая или своя самописная…
Объекты, которые мы передаем, могут быть и бизнес объектами, или их производными (объекты, которые содержат лишь часть данных бизнес объекта, нужных для передачи).
У меня чаще всего получались производные, а у объекта бизнес логики были методы типа setSubObjectData и getSubObjectData
И ещё раз повторюсь, речь идет о том, чтобы снизить трудоемкость.
Если проект не очень большой, и не очень сложный, то быстрее будет сделать на чем-нибудь готовом. Тот же SOAP в java делается в пару аннотаций в классе для jdk6.
В том же EJB последних версиях тоже есть возможность делать контейнеры-вебсервисы в одну строчку.
Что лучше, написать кучу мапперов, роутеров урлов. и прочее… Ведь их же писать нужно. Что лучше 1 строка или 300 строк? Что будет быстрее разработать? Где будет меньше ошибок?
Если нет каких либо сложных проблем использованием SOAP, то такой путь чуть быстрее. Можно сократить время разработки-отладки.
Велосипеды нынче не в почете, а ещё они могут ломаться.
А начальство ох как этого не любит, при каждой поломке начинает ныть, мол нужно было использовать стандартную или такую-то чужую. Вот приходится взвешивать что лучше чужая или своя самописная…
Изначально у меня речь не шла только об изменениях структуры. И без этого есть где косячить, но всё же в ответ на:
ИХМО проверять лучше структуру, а не данные.
можно подобрать ситуацию, когда при некотором изменении структуры первые 1000 XML-к будут валидны по старому валидатуру, а 1001 первый стал не валиден.
И как это ловить?
Иногда оно всплывает через месяц, иногда через год. У меня было через пару месяцев, под конец проекта(проект был на 3-4 месяца). Пришлось попотеть, чтобы успеть. Да и понервничать.
А почему оно должно отвалиться, и почему оно не отвалится при неREST'е?
ИХМО проверять лучше структуру, а не данные.
можно подобрать ситуацию, когда при некотором изменении структуры первые 1000 XML-к будут валидны по старому валидатуру, а 1001 первый стал не валиден.
И как это ловить?
Иногда оно всплывает через месяц, иногда через год. У меня было через пару месяцев, под конец проекта(проект был на 3-4 месяца). Пришлось попотеть, чтобы успеть. Да и понервничать.
Открою страшную тайну: данные надо проверять ВСЕГДА, даже если мы берем их по SOAP'у
Про это никто не спорит, вопрос о том, как проверять. Какова трудоемкость этих проверок.
> SOAP берет часть работы по валидации данных на себя
Что мещает встроить валидацию данных в REST-сервис?
Что мещает встроить валидацию данных в REST-сервис?
Опять, SOAP это все делает автоматически, а для REST еще надо будет потрудиться
> SOAP это все делает автоматически
Не надо рассказывать сказки. Ничего SOAP не делает автоматически. Вернее, не более автоматически чем любая другая компьютерная фигня. Если вы про валидацию по DTD/Schema, что что мешает иметь ее для REST?
Не надо рассказывать сказки. Ничего SOAP не делает автоматически. Вернее, не более автоматически чем любая другая компьютерная фигня. Если вы про валидацию по DTD/Schema, что что мешает иметь ее для REST?
> Не надо рассказывать сказки. Ничего SOAP не делает автоматически. Вернее, не более автоматически чем любая другая компьютерная фигня. Если вы про валидацию по DTD/Schema, что что мешает иметь ее для REST?
>> то с SOAP конечно легче — он сам найдет все изменеия структуры сообщений и внесет поправки.
>С какого перепугу он найдет это сам? И что мешает сделать такое же для REST?
В обоих каментах я имею в виду, что генерация прокси сделает за нас всю работу — и не позволит передать/получить не тот тип, и в случае измений на сервере позволит перегенерить клиента.
>> то с SOAP конечно легче — он сам найдет все изменеия структуры сообщений и внесет поправки.
>С какого перепугу он найдет это сам? И что мешает сделать такое же для REST?
В обоих каментах я имею в виду, что генерация прокси сделает за нас всю работу — и не позволит передать/получить не тот тип, и в случае измений на сервере позволит перегенерить клиента.
Что мешает сгенерировать прокси для REST'а?
Отсутствие инструментов которые могут это сделать? И косвенно то, что нету WSDL (или WADL).
Я не прав?
Я не прав?
> Отсутствие инструментов которые могут это сделать?
Почему у меня на работе они есть? ;) Да, их пришлось написать самостоятельно, но это не так много кода.
> И косвенно то, что нету WSDL (или WADL).
Что мешает адаптировать эти или похожие инструменты к REST'у? ;)
Почему у меня на работе они есть? ;) Да, их пришлось написать самостоятельно, но это не так много кода.
> И косвенно то, что нету WSDL (или WADL).
Что мешает адаптировать эти или похожие инструменты к REST'у? ;)
Проблема не в инструментах. Такие инструменты есть. Можно генерить код из WADL в той же idea от JetBrains.
Проблема 1, это работает только для Javа клиентов. В динамических языках всё динамическое. Поэтому если сильно хочется, прокси придется делать самому.
Идеология SOAP уже говорит, что нужно проверять данные. Поэтому все клиенты SOAP как-то реализуют поддержку валидации, без нее же ничего работать не будет.
Проблема 2, чтобы генерить прокси для REST, нужно сначала иметь файл WADL для этого сервиса. Я пока ещё не видел ни одного популярного сервиса REST, который бы предоставлял WADL файл(скажите мне, если найдете такой, попробую погенирить для него прокси на java, интересно, будет ли вообще работать).
Скорее наоборот, часто разработчики совсем отходят в сторону от REST(когда по одному урлу доступно несколько разных типов объектов с одной шапкой и разными данными внутри).
Проблема 1, это работает только для Javа клиентов. В динамических языках всё динамическое. Поэтому если сильно хочется, прокси придется делать самому.
Идеология SOAP уже говорит, что нужно проверять данные. Поэтому все клиенты SOAP как-то реализуют поддержку валидации, без нее же ничего работать не будет.
Проблема 2, чтобы генерить прокси для REST, нужно сначала иметь файл WADL для этого сервиса. Я пока ещё не видел ни одного популярного сервиса REST, который бы предоставлял WADL файл(скажите мне, если найдете такой, попробую погенирить для него прокси на java, интересно, будет ли вообще работать).
Скорее наоборот, часто разработчики совсем отходят в сторону от REST(когда по одному урлу доступно несколько разных типов объектов с одной шапкой и разными данными внутри).
> Проблема 1, это работает только для Javа клиентов. В динамических языках всё динамическое.
А других языков крому Java и динамики у нас нет совсем, ага ;)
> Идеология SOAP уже говорит, что нужно проверять данные. Поэтому все клиенты SOAP как-то реализуют поддержку валидации, без нее же ничего работать не будет.
Идология программирования говорит: надо проверять любые данные на входе. Если у нас идет обмен XML'ем, то банальную проверку по схеме можно сделать, по-моему, в любом языке
> чтобы генерить прокси для REST, нужно сначала иметь файл WADL для этого сервиса.
Что вы имеете в виду по «прокси для REST»?
А других языков крому Java и динамики у нас нет совсем, ага ;)
> Идеология SOAP уже говорит, что нужно проверять данные. Поэтому все клиенты SOAP как-то реализуют поддержку валидации, без нее же ничего работать не будет.
Идология программирования говорит: надо проверять любые данные на входе. Если у нас идет обмен XML'ем, то банальную проверку по схеме можно сделать, по-моему, в любом языке
> чтобы генерить прокси для REST, нужно сначала иметь файл WADL для этого сервиса.
Что вы имеете в виду по «прокси для REST»?
Что вы имеете в виду по «прокси для REST»?
Какую-нибудь прослойку, которую можно спросить что-то типа.
— вот тебе ID, дай мне объект.
— или на тебе объект, иди и сохрани его.
— или вот тебе критерии, дай мне массив объектов
— или дай мне массив всех объектов
Причем объекты мы можем написать сами или получить их из того же WADL. Там же мы получим и урлы да параметры, по которым нужно обращаться.
Для Ruby есть прикольная библиотека ActiveResource. Построена по принципу шаблона проектирования ActiveRecord. Использовать приблизительно так же.
На Java RestTemplate от Spring. Чтобы там получать и отсылать сложные объекты, нужно их маппить в XML. Маппинг приходится описывать отдельно.
и так далее…
Ну, это банальный маппер URI <-> бизнес объект. Как вы уже сами показали, в некоторых языках это доведено вообще до полного автоматизма :)
Для сложных систем, думаю, автосгенеренный SOAP не поможет, потому что для разных объектов понадобятся абсолютно разные уровни доступа вплоть о рахного доступа к разным полям внутри объекта. Лопатить придется вручную.
Для сложных систем, думаю, автосгенеренный SOAP не поможет, потому что для разных объектов понадобятся абсолютно разные уровни доступа вплоть о рахного доступа к разным полям внутри объекта. Лопатить придется вручную.
Простите, прочитал внимательнее комментарий.
Расскажите подробней: что вы делали, какие инструменты
Расскажите подробней: что вы делали, какие инструменты
>Почему у меня на работе они есть? ;) Да, их пришлось написать самостоятельно, но это не так много кода.
>Что мешает адаптировать эти или похожие инструменты к REST'у? ;)
думаю, можно вывести общую мысль о том, что надо анализировать каждую задачу отдельно чтобы определить наиболее подходящий вариант взаимодействия.
Иногда SOAP может многократно ускорить процесс разработки, однако часто — нет. Думаю, мы все понимаем почему.
Согласен с png, интересно узнать про инструменты на Вашей работе) на чем написаны, что делают, насколько универсальны?
У меня у друга на проекте они должны из .Net юзать REST сервис, возвращающий довольно накрученные объекты. Они хорошо подумали, как лучше реализовать задачу, и решили делать это с помощью вручную написанных классов с расставленными аттрибутами сериализации. Запросы посылают через HttpClient, ответ десериализуют каким-то json-сериалайзером. Вроде бы достаточно просто и красиво, но все же полная автоматизация.
>Что мешает адаптировать эти или похожие инструменты к REST'у? ;)
думаю, можно вывести общую мысль о том, что надо анализировать каждую задачу отдельно чтобы определить наиболее подходящий вариант взаимодействия.
Иногда SOAP может многократно ускорить процесс разработки, однако часто — нет. Думаю, мы все понимаем почему.
Согласен с png, интересно узнать про инструменты на Вашей работе) на чем написаны, что делают, насколько универсальны?
У меня у друга на проекте они должны из .Net юзать REST сервис, возвращающий довольно накрученные объекты. Они хорошо подумали, как лучше реализовать задачу, и решили делать это с помощью вручную написанных классов с расставленными аттрибутами сериализации. Запросы посылают через HttpClient, ответ десериализуют каким-то json-сериалайзером. Вроде бы достаточно просто и красиво, но все же полная автоматизация.
Они хорошо подумали, как лучше реализовать задачу, и решили делать это с помощью вручную написанных классов с расставленными аттрибутами сериализации. Запросы посылают через HttpClient, ответ десериализуют каким-то json-сериалайзером. Вроде бы достаточно просто и красиво, но все же полная автоматизация.
Я тоже так делал, только в Java. К тому же ответ тоже можно десериализовать в объект по тем же аннотациям. То есть этот фокус в обе стороны работает. К тому же, легко покрывается тестами.
Проблема в том, что эти объекты пришлось руками описывать. Использовать WADL не вышло, сторонний сервис его не предоставлял.
> интересно узнать про инструменты на Вашей работе) на чем написаны, что делают, насколько универсальны?
mochiweb + webmachine + erlang. Центральный диспетчер + буквально 200-300 строчек кода для конвертации бизнес-объектов туда-сюда.
В принципе, велосипед, просто очень много разнородных данных
mochiweb + webmachine + erlang. Центральный диспетчер + буквально 200-300 строчек кода для конвертации бизнес-объектов туда-сюда.
В принципе, велосипед, просто очень много разнородных данных
с erlang никогда не сталкивался.
Спасибо за ответ.
Спасибо за ответ.
К сожалению, более развернуто ответить не смогу, потому что NDA :)
Но принцип чем-то примерно похожий на SOAP: для бизнес объектов описываются их схемы, исходя из которых можно получить автоматический doc с описанием типа в таком стиле:
и т.п. (но в более удобоваримом формате).
Имея на руках схему маппер, опираясь на всю мощб паттерн-матчинга, тупо может любое поле превратить в любое представление. Скажем, есть поле role_id, которое ссылается на другую сущность, доступную по сслыке.
схема:
конвертер:
ну и потом генератор на основе этих данных генерирует либо xml либо json либо любой другой формат.
Это очень поверхностно, естественно.
Но принцип чем-то примерно похожий на SOAP: для бизнес объектов описываются их схемы, исходя из которых можно получить автоматический doc с описанием типа в таком стиле:
GET http://site/entity/doc
<entity>
<fields>
<id>
<type>integer</type>
</id>
<roles>
<rel>http://site/schemas/roles</rel>
<href>/entity/roles</href>
</roles>
</fields>
</entity>
и т.п. (но в более удобоваримом формате).
Имея на руках схему маппер, опираясь на всю мощб паттерн-матчинга, тупо может любое поле превратить в любое представление. Скажем, есть поле role_id, которое ссылается на другую сущность, доступную по сслыке.
схема:
....
% [{имя наружу, имя в базе данных}, нзвание конвертирующей функции]
[{role, role_id}, link_to_role]
конвертер:
link_to_role(Value) ->
[{rel, "http://site/schemas/role"}, {href, "http://site/role/" ++ Value}]
ну и потом генератор на основе этих данных генерирует либо xml либо json либо любой другой формат.
Это очень поверхностно, естественно.
1c (начиная с 8.1) есть поддержка сервисов:
v8.1c.ru/overview/Term_000000164
v8.1c.ru/overview/Term_000000273
v8.1c.ru/overview/Term_000000164
v8.1c.ru/overview/Term_000000273
1. Вы смешали в одну кучу протокол и архитектуру, как уже выше отметили, REST — это архитектура, а SOAP — это один из протоколов, полностью отвечающий архитектуре REST, поэтому противопоставлять их не следует, а то, что Вы называете REST, после некоторого смущения, мне кажется, я все же догадался, REST-ом Вы называете AJAX запросы через HTTP к определенному URL с возвратом JSON, так же? Ну тогда замените в статье это на AJAX/JSON — будет понятнее, т.к. под REST можно понимать все что угодно, ходящее через HTTP как через транспорт.
2. Основная ущербность REST подхода заключается в отсутствии машины состояний на сервере. Ну честное слово, тот кто хоть раз писал протокол на сокетах, уже не может изголяться и наворачивать костыли, стараясь впихнуть все в заранее инвалидную модель с независимыми друг от друга вызовами, если на сокетах — смакота: установил соединение, когда нужно клиент прислал запрос серверу, а когда нужно сервер прислал кленту событие даже без запроса на это, просто потому, что на сервере изменилось состояние бизнес-объекта в памяти или в базе, в результате работы другого клиента или фонового серверного процесса. Не нужно постоянно пересылать состояние клиента при каждом вызове на сервер, там уже есть объект, хранящий состояние и если нужно, даже структуры данных специально для подключенного клиента. Именно так общались приложения в «мезозойскую эру», и поверьте, это было гораздо более духовным общением, даже учитывая, что все придумывали свои протоколы. Казалось бы, REST придумали для улучшения жизни, но мы видим, что он привел WEB коммуникации к полному фиаско в двухсторонней клиент-серверной интерактивности и высоконагруженности, именно поэтому сейчас идет опять возврат к системам с машиной состояния и к асинхронному взаимодействию, со старой моделью потоковости, когда не нужно «форкать» жирный веб сервер в памяти для обработки нового подключения.
Еще высылаю ссылки на две мои старые статьи по теме, возможно, будет интересно:
Интеграция на уровне вызовов или мета-данных?
REST и CRUD против RPC
2. Основная ущербность REST подхода заключается в отсутствии машины состояний на сервере. Ну честное слово, тот кто хоть раз писал протокол на сокетах, уже не может изголяться и наворачивать костыли, стараясь впихнуть все в заранее инвалидную модель с независимыми друг от друга вызовами, если на сокетах — смакота: установил соединение, когда нужно клиент прислал запрос серверу, а когда нужно сервер прислал кленту событие даже без запроса на это, просто потому, что на сервере изменилось состояние бизнес-объекта в памяти или в базе, в результате работы другого клиента или фонового серверного процесса. Не нужно постоянно пересылать состояние клиента при каждом вызове на сервер, там уже есть объект, хранящий состояние и если нужно, даже структуры данных специально для подключенного клиента. Именно так общались приложения в «мезозойскую эру», и поверьте, это было гораздо более духовным общением, даже учитывая, что все придумывали свои протоколы. Казалось бы, REST придумали для улучшения жизни, но мы видим, что он привел WEB коммуникации к полному фиаско в двухсторонней клиент-серверной интерактивности и высоконагруженности, именно поэтому сейчас идет опять возврат к системам с машиной состояния и к асинхронному взаимодействию, со старой моделью потоковости, когда не нужно «форкать» жирный веб сервер в памяти для обработки нового подключения.
Еще высылаю ссылки на две мои старые статьи по теме, возможно, будет интересно:
Интеграция на уровне вызовов или мета-данных?
REST и CRUD против RPC
По поводу пункта 1. Вебсервису использующему SOAP ничто не запрещает быть stateful. Rest сервис таким быть не может. Да, мы сравниваем архитектуру и протокол, но стоит понимать что то что использует SOAP может работать как REST, но не все, что SOAP есть REST.
Вообще говоря, «машина состояния» — это в высоконагруженных проектах не всегда хорошо, так как по мимо трафика приходится еще и ресурсы на память состояния трэкать. Плюс встают вопросы масштабируемости такой «машины состояния». Здесь уже не сделаешь дешевое горизонтальное масштабирование, надо продумывать миграцию сессий и данных, а также их безопасность.
если на сокетах — смакота: установил соединение, когда нужно клиент прислал запрос серверу, а когда нужно сервер прислал кленту событие даже без запроса на этоА сколько вы сокетов-то откроете одновременно? 100 запросов в секунду и прощай пул и здравствуй Service is out of its capacity
Вообще говоря, «машина состояния» — это в высоконагруженных проектах не всегда хорошо, так как по мимо трафика приходится еще и ресурсы на память состояния трэкать. Плюс встают вопросы масштабируемости такой «машины состояния». Здесь уже не сделаешь дешевое горизонтальное масштабирование, надо продумывать миграцию сессий и данных, а также их безопасность.
Но на HTTP идет поток запросов, по сути, клиент или «долбит» сервер GET-ами или при каждой операции на клиенте или при ожидании, другой вариант — при ожидании серверного события делать «long pooling» (длинные http-запросы), но тогда отдельный поток выделяется на сервере на обработку долгого запроса и висит пока не отпадет таймаут или пока событие не случится, при этом, он же на сервере должен взаимодействовать с базой или файловой системой или с другим процессом, ну который реализует машину состояний. Вот недавно перевел проект один с HTTP на сокеты, 10000 одновременно активных клиентов, большая их активность, более 5000 GET-ов в секунду, Apache расплодился в памяти (уверен, что IIS тоже будет вести себя лучшим образом), все CPU уходило на переключение между контекстами, а что получилось при переходе на сокеты, 10 серверных сокетов открываем, клиенты распределяются между ними по 1000 клиентов на сокет, каждый сокет обрабатывается отдельным потоком внутри одного приложения, вообще поток запросов уменьшился, ведь не нужно долбить сервер, сокеты по большей части ждут и иногда присылают запросы, соединение держим, его не нужно разрывать, машина состояния одна, все начало жить, а на Apache более 1500 клиентов не удавалось запустить.
А можно подробнее про задачу? интересно
К сожалению, это коммерческий проект и я ограничен в раскрытии деталей, могу только сказать, что переход на сокеты позволил сократить трафик более, чем на 75%, т.к. одиночные HTTP запросы дают большие накладные расходы на обертку (заголовки, служебные данные) и требуют постоянного опроса сервера в режиме POOL, так же удалось достигнуть времени синхронности при одновременной рассылке серверного события на 10000 клиентов в рамках 5 секунд, что для HTTP, даже с применением LONG POOL — абсолютно не реально. Использование памяти сократилось в десятки раз, от переключения контекстов почти ушли, вообще конечно пришлось балансировать между соединением клиентов к одному процессу и колличеством этих самых процессов. Дело в том, что в одном процессе обработка всех клиентов же идет в цикле, а пройти 1000 сокетов в цикле — это тоже задача не слабая, и распределив клиентов на 10 пулов мы вполне нашли для себя баланс. Обработка же 10000 HTTP запросов одновременно — убьет любое железо.
Может я чего-то не понимаю в SOAP, тогда поясните мне, как Вы организуете машину состояний, если SOAP базируется на HTTP транспорте, который идеологически стейтлесс и без установления соединения?
Через идентификатор сессии.
Он хранится в кукисах и пересылается при каждом запросе к серверу.
Он хранится в кукисах и пересылается при каждом запросе к серверу.
Это уже отход от идеологии, а как же масштабируемость, как же великие диссертационные идеи Филдинга? Да пусть Филдинг идет лесом, нам нужно писать реальные живые системы, интерактивные, с высокой скорость реакции в GUI, я вот за более 15 лет практической разработки не встречал ни одной серьезной задачи, где бы не было нужно состояние. Все используют состояние, если пишут что-то отличное от банального статического сайта, хотя бы в виде сессий, но сессии — это не лучший вариант хранить состояние, только представьте, сессия все время сериализируется, чтобы храниться между запросами и десериализируется при восстановлении процесса, а что, если нам нужно хранить в сессии 2мб матрицу или набор данных подготовленный, с которым работает пользователь в каком-то финансовом приложении, при больших нагрузках — это большие расходы процессора. Как, кстати, и расходы на создание и разрушение объектов в памяти, необходимых для обслуживания клиента, для интерактивных систем это не годится, все должно быть развернуто прямо в памяти между запросами.
Это для SOAP.
В REST же сервис не имеет состояния — это один из принципов, описанных Филдингом.
В REST же сервис не имеет состояния — это один из принципов, описанных Филдингом.
Филдинг маразматик, пусть он приведет жизненные примеры применения REST без сессий.
Или Вы приведите пару примеров где возможен REST, Филдинг тут не читает, надеюсь.
REST не отменяет сессий :-\
Ну и все сервисы Амазона, по сути, REST'овые
Ну и все сервисы Амазона, по сути, REST'овые
А как же так получается, что Амазон показывает мне:
— товары, которые я недавно смотрел
— товары которые часто смотрят люди, купившие то же, что и я купил недавно
— товары, отложенные мной в вишлист
— товары, рекомендованные для моего потребительского профиля
Разве все это не на основе достаточно большого состояния сессии мне выдается?
— товары, которые я недавно смотрел
— товары которые часто смотрят люди, купившие то же, что и я купил недавно
— товары, отложенные мной в вишлист
— товары, рекомендованные для моего потребительского профиля
Разве все это не на основе достаточно большого состояния сессии мне выдается?
> А как же так получается, что Амазон показывает мне:
Хотя говоря в виду сервисы Амазона, я имел в виду скорее aws.amazon.com/
Но, кстати, Твиттер тоже сидит на REST'е. В частности, его веб-морда является клиентом к его же API.
REST не отменяет сессий
Хотя говоря в виду сервисы Амазона, я имел в виду скорее aws.amazon.com/
Но, кстати, Твиттер тоже сидит на REST'е. В частности, его веб-морда является клиентом к его же API.
Это не прикладные сервисы, это скорее IAS — инфраструктурные сервисы, но вот чтобы GovCloud, Messaging, Billing были без состояния — не поверю. Вы их исследовали? Я — нет.
> Это не прикладные сервисы, это скорее IAS — инфраструктурные сервисы
И что это меняет? Там точно так же нужна, например, идентификация пользователя на каждый чих.
> тобы GovCloud, Messaging, Billing были без состояния — не поверю
Не имею ни малейшего представления, о чем вы сейчас говорите. Также предполагаю, что вы неправильно представляете состояние.
И что это меняет? Там точно так же нужна, например, идентификация пользователя на каждый чих.
> тобы GovCloud, Messaging, Billing были без состояния — не поверю
Не имею ни малейшего представления, о чем вы сейчас говорите. Также предполагаю, что вы неправильно представляете состояние.
Мы начали обсуждать ПО, о котором оба не имеем представления, мы его не использовали, в этом лучше закруглиться.
Но в чем я действительно уверен, так это в том, что невозможно написать ни один мало мальски серьезный сервис без состояния, хранящегося хотябы в сессии или в памяти или в базе или на диске или во viewstate или в другом месте, т.к. класс задач не требующих состояния слишком мал, вот, разве что, приведенный Вами Twitter.
Но в чем я действительно уверен, так это в том, что невозможно написать ни один мало мальски серьезный сервис без состояния, хранящегося хотябы в сессии или в памяти или в базе или на диске или во viewstate или в другом месте, т.к. класс задач не требующих состояния слишком мал, вот, разве что, приведенный Вами Twitter.
> Мы начали обсуждать ПО, о котором оба не имеем представления, мы его не использовали, в этом лучше закруглиться.
Я использую Amazon S3 и Твиттер. Если вы ими не пользуетесь, не значит, что ими не пользуются ваши оппоненты.
> то невозможно написать ни один мало мальски серьезный сервис без состояния, хранящегося хотябы в сессии или в памяти или в базе или на диске или во viewstate или в другом месте
Вы просто, виимо, вообще не поняли, о чем REST :-\ Насчет состояния REST говорит только одно: сервер не хранит информацию о клиенте между запросами, клиент обязан передавать ему всю информацию, необходимую для запроса. То есть сам клиент должен обеспечивать сессию. Это — если очень грубо.
Вообще, это русским по белому написано в википедии. А дальше — в обязательной к прочтению книге RESTful Web Services
Я использую Amazon S3 и Твиттер. Если вы ими не пользуетесь, не значит, что ими не пользуются ваши оппоненты.
> то невозможно написать ни один мало мальски серьезный сервис без состояния, хранящегося хотябы в сессии или в памяти или в базе или на диске или во viewstate или в другом месте
Вы просто, виимо, вообще не поняли, о чем REST :-\ Насчет состояния REST говорит только одно: сервер не хранит информацию о клиенте между запросами, клиент обязан передавать ему всю информацию, необходимую для запроса. То есть сам клиент должен обеспечивать сессию. Это — если очень грубо.
Вообще, это русским по белому написано в википедии. А дальше — в обязательной к прочтению книге RESTful Web Services
Amazon S3 не является прикладным сервисом, в нем нет серверной бизнес-логики как таковой, это сервис инфраструктуры, это очень узкий клсс задач, по сути это сеть доставки данных. Таких задач на пальцах обоих рук можно пересчитать, а вот прикладных задач, которых подавляющее множество, как, например, бизнес-приложения, торговые, финансовые, платежные, социальные, CRM, ERP, документооборот, SCM, CAD, и многие многие другие прикладные приложения, составляющие 99% всего ПО — невозможны без состояния.
Что такое REST я прекрасно понимаю и прочел про это во многих интерпретациях. Сессия и состояние должны храниться на сервере между запросами для реализации любого прикладного приложения. Если же сессию обеспечивает клиент, то он пересылает это состояние каждый раз на сервер при запросе и получает его измененное назад после выполнения запроса, и к чему это приводит? Вы видели ПО написанное с использованием viewstae, это огромный кусок данных туда-сюда носится без всякого толка, кроме того, ни какой секьюрности, на клиенте это состояние можно подменить очень просто, его могут перехватить, оно тормозит работу системы и, в общем случае, все равно не решает проблемы REST, т.к. состояние одного пользователя лишено возможности взаимодействия с состоянием другого, поэтому групповая работа исключена, серверные события исключены, и сервер должен всегда доверять клиенту, что тот не подсунет ему какое-то левое состояние, там тысячи проверок нужно делать, чтобы обезопасить приложение от взлома.
Что такое REST я прекрасно понимаю и прочел про это во многих интерпретациях. Сессия и состояние должны храниться на сервере между запросами для реализации любого прикладного приложения. Если же сессию обеспечивает клиент, то он пересылает это состояние каждый раз на сервер при запросе и получает его измененное назад после выполнения запроса, и к чему это приводит? Вы видели ПО написанное с использованием viewstae, это огромный кусок данных туда-сюда носится без всякого толка, кроме того, ни какой секьюрности, на клиенте это состояние можно подменить очень просто, его могут перехватить, оно тормозит работу системы и, в общем случае, все равно не решает проблемы REST, т.к. состояние одного пользователя лишено возможности взаимодействия с состоянием другого, поэтому групповая работа исключена, серверные события исключены, и сервер должен всегда доверять клиенту, что тот не подсунет ему какое-то левое состояние, там тысячи проверок нужно делать, чтобы обезопасить приложение от взлома.
> Amazon S3 не является прикладным сервисом, в нем нет серверной бизнес-логики как таковой, это сервис инфраструктуры, это очень узкий клсс задач, по сути это сеть доставки данных.
Какая разница? Вы спросили пример решений на REST, я привел
> Если же сессию обеспечивает клиент, то он пересылает это состояние каждый раз на сервер при запросе и получает его измененное назад после выполнения запроса, и к чему это приводит?
К великолепно масштабиуремой горизонтально архитектуре. Более того, подавляющее большинство высоконагруженных проектов всеми силами стараются избавиться от сессий на сервере или как можно сильнее уменьшать зависимость от них.
> Вы видели ПО написанное с использованием viewstae, это огромный кусок данных туда-сюда носится без всякого толка, кроме того, ни какой секьюрности,
И что эта фраза про viewstate должна показать? Что REST плохой, или что? Viewstate к REST'у вообще никакого отношения не имеет
> и сервер должен всегда доверять клиенту, что тот не подсунет ему какое-то левое состояние, там тысячи проверок нужно делать, чтобы обезопасить приложение от взлома.
Мде, и это говорит человек, который якобы знает, что такое REST :-\
Если на пальцах:
— есть какие-то ресурсы, связанные с каим-либо человеком X
— при попытке получить/изменить эти ресурсы другим человеком Y выдаем 503 Not Authorized
— при авторизации человека X сохраняем на клиенте информацию, необходимую для идентификации этого пользователя (например, в виде Secure Cookie)
— при попытке получить/изменить ресурс, связанный с человеком X, получаем с клиента необходимую информацию, идентифицируем человека, выдаем/изменяем требуемый ресурс.
Сложно? Нет, элементарно.
Что такое ресурс? Да все, что угодно :-\
— shopping cart
— отдельная позиция в этой корзине
— профиль пользователя
— банковский счет пользователя
— … пофиг что пользователя
Для просмотра/изменения/удаления этих ресурсов все, что нам нужно — это идентифицировать пользователя.
Какая разница? Вы спросили пример решений на REST, я привел
> Если же сессию обеспечивает клиент, то он пересылает это состояние каждый раз на сервер при запросе и получает его измененное назад после выполнения запроса, и к чему это приводит?
К великолепно масштабиуремой горизонтально архитектуре. Более того, подавляющее большинство высоконагруженных проектов всеми силами стараются избавиться от сессий на сервере или как можно сильнее уменьшать зависимость от них.
> Вы видели ПО написанное с использованием viewstae, это огромный кусок данных туда-сюда носится без всякого толка, кроме того, ни какой секьюрности,
И что эта фраза про viewstate должна показать? Что REST плохой, или что? Viewstate к REST'у вообще никакого отношения не имеет
> и сервер должен всегда доверять клиенту, что тот не подсунет ему какое-то левое состояние, там тысячи проверок нужно делать, чтобы обезопасить приложение от взлома.
Мде, и это говорит человек, который якобы знает, что такое REST :-\
Если на пальцах:
— есть какие-то ресурсы, связанные с каим-либо человеком X
— при попытке получить/изменить эти ресурсы другим человеком Y выдаем 503 Not Authorized
— при авторизации человека X сохраняем на клиенте информацию, необходимую для идентификации этого пользователя (например, в виде Secure Cookie)
— при попытке получить/изменить ресурс, связанный с человеком X, получаем с клиента необходимую информацию, идентифицируем человека, выдаем/изменяем требуемый ресурс.
Сложно? Нет, элементарно.
Что такое ресурс? Да все, что угодно :-\
— shopping cart
— отдельная позиция в этой корзине
— профиль пользователя
— банковский счет пользователя
— … пофиг что пользователя
Для просмотра/изменения/удаления этих ресурсов все, что нам нужно — это идентифицировать пользователя.
Так чем же, все таки, ресурс отличается от состояния?
Тем, что серверу не надо его хранить между запросами. Для него каждый новый запрос — это запрос от абсолютно нового клиента.
В итоге для одного и того же посетителя на одном и том же сайте запрос «добавить в шоппинг карт» и «чекаут» могут выполнить два абсолютно разных сервера (в идеальных условиях — даже географически уаленные друг от друга).
В итоге для одного и того же посетителя на одном и том же сайте запрос «добавить в шоппинг карт» и «чекаут» могут выполнить два абсолютно разных сервера (в идеальных условиях — даже географически уаленные друг от друга).
Что-то Вы путаетесь, чуть выше Вы говорите, что «Viewstate к REST'у вообще никакого отношения не имеет», как же это не имеет, если вся информация о товарах в корзине хранится в viewstate, передается на сервер при каждом запросе и получается обратно при каждом ответе?
А базы данных на сервере нет? Файлов нет? Все равно будет задача держать данные в базе и на диске в синхронном состоянии между распределенными серверами, так почему же не хранить состояние на сервере и почему бы не синхронизировать его между несколькими серверами или почему бы не выделить отдельный бездисковый сервер специально для состояний, хранить в чем-то типа memcached?
А базы данных на сервере нет? Файлов нет? Все равно будет задача держать данные в базе и на диске в синхронном состоянии между распределенными серверами, так почему же не хранить состояние на сервере и почему бы не синхронизировать его между несколькими серверами или почему бы не выделить отдельный бездисковый сервер специально для состояний, хранить в чем-то типа memcached?
> Что-то Вы путаетесь, чуть выше Вы говорите, что «Viewstate к REST'у вообще никакого отношения не имеет», как же это не имеет, если вся информация о товарах в корзине хранится в viewstate, передается на сервер при каждом запросе и получается обратно при каждом ответе?
Это — всего лишь одна из возможных реализаций. Из одной частной реализации вы раздуваете слона и переносите это на REST в целом :-\
> А базы данных на сервере нет? Файлов нет?
Как вы там говорили? «Что такое REST я прекрасно понимаю и прочел про это во многих интерпретациях. » Что-то у меня боооольшущие сомнения в правдивости этого утверждения. Открываем ближайшую википедию:
Почему? Потому что единственным ограничением на состояние является:
Что это значит? Это значит, что для любого запроса к серверу клиент является новым и неизвестным клиентом, даже если это — один и тот же бот с одного и того же IP.
> Все равно будет задача держать данные в базе и на диске в синхронном состоянии между распределенными серверами
Ну храните, кто вам мешает-то?
Единственное ограничение: сервер не должен хранить контекст клиента между запросами. Это значит, что:
— запрос 1, shopping_cart/add может обработать сервер 1
— запрос 2, shopping_cart/view может обработать сервер 2
— запрос 3, shopping_cart_item/update может обработать сервер 3
— запрос 4, shopping_cart/checkout может обработать, например, опять сервер 1
При этом они все будут независимы друг от друга и не зависить от контекста сессий или пользователей друг у друга. Как только вы начинаете где-то что-то хранить (типа «пользователь на шаге 2 чекаута»), все, приплыли — добро пожаловать в адъ синхронизаций состояний между серверами и попытками удержать клиента на том сервере, который следит за его сессией.
Это — всего лишь одна из возможных реализаций. Из одной частной реализации вы раздуваете слона и переносите это на REST в целом :-\
> А базы данных на сервере нет? Файлов нет?
Как вы там говорили? «Что такое REST я прекрасно понимаю и прочел про это во многих интерпретациях. » Что-то у меня боооольшущие сомнения в правдивости этого утверждения. Открываем ближайшую википедию:
Сервер может быть с состоянием (The server can be stateful)
Почему? Потому что единственным ограничением на состояние является:
Взаимодействие клиент-сервер ограничивается далее отсутствием сохранения контекста клиента на сервере между запросами.
Что это значит? Это значит, что для любого запроса к серверу клиент является новым и неизвестным клиентом, даже если это — один и тот же бот с одного и того же IP.
> Все равно будет задача держать данные в базе и на диске в синхронном состоянии между распределенными серверами
Ну храните, кто вам мешает-то?
Единственное ограничение: сервер не должен хранить контекст клиента между запросами. Это значит, что:
— запрос 1, shopping_cart/add может обработать сервер 1
— запрос 2, shopping_cart/view может обработать сервер 2
— запрос 3, shopping_cart_item/update может обработать сервер 3
— запрос 4, shopping_cart/checkout может обработать, например, опять сервер 1
При этом они все будут независимы друг от друга и не зависить от контекста сессий или пользователей друг у друга. Как только вы начинаете где-то что-то хранить (типа «пользователь на шаге 2 чекаута»), все, приплыли — добро пожаловать в адъ синхронизаций состояний между серверами и попытками удержать клиента на том сервере, который следит за его сессией.
Википедия не есть истина в последней инстанции, там же явное противоречие написано, которое Вы только что процитировали, сначала «Взаимодействие клиент-сервер ограничивается далее отсутствием сохранения контекста клиента на сервере между запросами.» и потом «Сервер может быть с состоянием». Тогда чем отличается состояние от контекста клиента между запросами?
Мдеее :-\
У нас есть датчик в виде сервера. Он должен отключиться, когда на него приходит запрос определенного типа (например, overflow какой-нибудь). Запрос пришел, сервер отключился. У сервера есть состояние, но при этом принципы REST не нарушены. Парадокс? Никакого парадокса, если наконце-то сесть и почитать, что написано, блин:
У нас есть датчик в виде сервера. Он должен отключиться, когда на него приходит запрос определенного типа (например, overflow какой-нибудь). Запрос пришел, сервер отключился. У сервера есть состояние, но при этом принципы REST не нарушены. Парадокс? Никакого парадокса, если наконце-то сесть и почитать, что написано, блин:
Взаимодействие клиент-сервер ограничивается далее отсутствием сохранения контекста клиента на сервере между запросами.
А какой именно из множества серверов переключается в новое состояние, если состояние не у клиента на сервере, а у сервера в целом, то вопрос синхронизации серверов стоит так же остро, от чего бежали, к тому и вернулись?
Ваш вопрос мне просто непонятен :-\
1. То, что у сервера может быть состояние, не означает, что оно у него обязательно есть
2. То, что у сервера есть состояние, не означает, что оно обязательно связано с клиентом
3. То, что у сервера есть состояние, никак не противоречит REST'У, потому что архитектура сервера в общем REST не волнует, REST накладывает ограничение только на клиент-серверное взаимодействие.
Если на пальцах: если у нас есть банальный load-balancer, и 10 серверов с состоянием вкл./выкл., то в случае, когда, скажем, 5 серверов получают состояние выкл., истема продолжает работать, как ни в чем не бывало, потому что ни один из серверов не держит никакой инфрмации по действиям клиента, они просто отвечают на запросы по выдаче/модификации определенных ресурсов.
Если на пальцах 2: у нас есть диспетчер X и load-balancer'ы A, B. Дипетчер отправляет запросы на ресурсы res1, res2, ..., res(N/2) на load-balancer A, а запроы на res(N/2+1)...resN — на load-balancer B. У каждого load-balancer'а в подчинении своя группа серверов. Таким образом, по сути, у каждого сервера есть свое состояние (отвечать только на определенные запросы), каждый из них может быть переведен в другое состояние (переведен из группы А в группу B и наоборот), но при этом системе в целом и клиентам в частности глубоко насрать на то, что происходит за точкой X. Ни один из серверов не содержит ни грамма информации о текущих действиях клиента. Каждый сервер обрабатывает строго запросы на выдачу и модификацию каких-то там ресурсов.
1. То, что у сервера может быть состояние, не означает, что оно у него обязательно есть
2. То, что у сервера есть состояние, не означает, что оно обязательно связано с клиентом
3. То, что у сервера есть состояние, никак не противоречит REST'У, потому что архитектура сервера в общем REST не волнует, REST накладывает ограничение только на клиент-серверное взаимодействие.
Если на пальцах: если у нас есть банальный load-balancer, и 10 серверов с состоянием вкл./выкл., то в случае, когда, скажем, 5 серверов получают состояние выкл., истема продолжает работать, как ни в чем не бывало, потому что ни один из серверов не держит никакой инфрмации по действиям клиента, они просто отвечают на запросы по выдаче/модификации определенных ресурсов.
Если на пальцах 2: у нас есть диспетчер X и load-balancer'ы A, B. Дипетчер отправляет запросы на ресурсы res1, res2, ..., res(N/2) на load-balancer A, а запроы на res(N/2+1)...resN — на load-balancer B. У каждого load-balancer'а в подчинении своя группа серверов. Таким образом, по сути, у каждого сервера есть свое состояние (отвечать только на определенные запросы), каждый из них может быть переведен в другое состояние (переведен из группы А в группу B и наоборот), но при этом системе в целом и клиентам в частности глубоко насрать на то, что происходит за точкой X. Ни один из серверов не содержит ни грамма информации о текущих действиях клиента. Каждый сервер обрабатывает строго запросы на выдачу и модификацию каких-то там ресурсов.
Поздравляю — это веб 1.0. А тенденции то сейчас как раз совершенно другие, вы посмотрите на самые высоконагруженные и раскрученные ресурсы:
1. Максимальная персонализация: отслеживается маршрут пользователя и составляется карта его интересов и предпочтений, соответственно этому персонализируется страница, т.е. показываются товары, новости, и т.д. самые релевантные для профиля пользователя.
2. Динамический контент- без перезагрузки страницы, по времени и по событиям перегружаются блоки, оперативно реагируя на состояние сервера в целом и на состояние клиентов
3. Интерактивность — система ведет постоянный диалог с пользователем
4. Взаимодействие между пользователями — как вот его без состояния сделать? Это же состояние одного пользователя должно взаимодействовать с состоянием другого.
И все это только касательно сайтов. Про прикладные информационные системы вообще говорить не приходится, они все с состоянием, это их суть.
Как же это все реализуется? Да очень просто, есть N серверов, и балансировщик, по идентификатору сессии, запросы пользователей распределяются равномерно по серверам. Кроме того, есть еще машина состояний, вынесенная из этих серверов как отдельный сервис. Общая машина состояний, бездискавая, тоже на M машинах запущенная, так, что каждое изменение состояни пишется сразу в M машин, а читается только из одной, любой.
1. Максимальная персонализация: отслеживается маршрут пользователя и составляется карта его интересов и предпочтений, соответственно этому персонализируется страница, т.е. показываются товары, новости, и т.д. самые релевантные для профиля пользователя.
2. Динамический контент- без перезагрузки страницы, по времени и по событиям перегружаются блоки, оперативно реагируя на состояние сервера в целом и на состояние клиентов
3. Интерактивность — система ведет постоянный диалог с пользователем
4. Взаимодействие между пользователями — как вот его без состояния сделать? Это же состояние одного пользователя должно взаимодействовать с состоянием другого.
И все это только касательно сайтов. Про прикладные информационные системы вообще говорить не приходится, они все с состоянием, это их суть.
Как же это все реализуется? Да очень просто, есть N серверов, и балансировщик, по идентификатору сессии, запросы пользователей распределяются равномерно по серверам. Кроме того, есть еще машина состояний, вынесенная из этих серверов как отдельный сервис. Общая машина состояний, бездискавая, тоже на M машинах запущенная, так, что каждое изменение состояни пишется сразу в M машин, а читается только из одной, любой.
> вы посмотрите на самые высоконагруженные и раскрученные ресурсы:
Цитирую самого себя парой комментариев выше:
Описанные вами пункты 1-5 не имеют никакого отношения к REST'у. Это — функциональность приложений. REST — архитектура приложений, которая никак не препятсвует реализации ни одного из этих пунктов
> Да очень просто, есть N серверов, и балансировщик, по идентификатору сессии, запросы пользователей распределяются равномерно по серверам.
Цитирую сам себя выше:
Вы явно не читаете, что вам пишут и не прилагаете никаких усилий понять, что вам пишут.
Цитирую самого себя парой комментариев выше:
подавляющее большинство высоконагруженных проектов всеми силами стараются избавиться от сессий на сервере или как можно сильнее уменьшать зависимость от них…
Твиттер тоже сидит на REST'е. В частности, его веб-морда является клиентом к его же API…
Описанные вами пункты 1-5 не имеют никакого отношения к REST'у. Это — функциональность приложений. REST — архитектура приложений, которая никак не препятсвует реализации ни одного из этих пунктов
> Да очень просто, есть N серверов, и балансировщик, по идентификатору сессии, запросы пользователей распределяются равномерно по серверам.
Цитирую сам себя выше:
подавляющее большинство высоконагруженных проектов всеми силами стараются избавиться от сессий на сервере или как можно сильнее уменьшать зависимость от них…
Если на пальцах:
— есть какие-то ресурсы, связанные с каим-либо человеком X
— при попытке получить/изменить эти ресурсы другим человеком Y выдаем 503 Not Authorized
— при авторизации человека X сохраняем на клиенте информацию, необходимую для идентификации этого пользователя (например, в виде Secure Cookie)
— при попытке получить/изменить ресурс, связанный с человеком X, получаем с клиента необходимую информацию, идентифицируем человека, выдаем/изменяем требуемый ресурс…
Единственное ограничение: сервер не должен хранить контекст клиента между запросами. Это значит, что:
— запрос 1, shopping_cart/add может обработать сервер 1
— запрос 2, shopping_cart/view может обработать сервер 2
— запрос 3, shopping_cart_item/update может обработать сервер 3
— запрос 4, shopping_cart/checkout может обработать, например, опять сервер 1
При этом они все будут независимы друг от друга и не зависить от контекста сессий или пользователей друг у друга…
Вы явно не читаете, что вам пишут и не прилагаете никаких усилий понять, что вам пишут.
dmitriid, спасибо, что держали тут удар, пока меня не было. Согласен со всем сказанным.
MarcusAurelius, я думаю, Вы не врете, что прочитали много всего по данному вопросу, просто у Вас совершенно другое восприятие, я бы сказал альтернативное восприятие.
Вы явно больше сталкивались с задачами, где удобнее работать через сокеты с установлением выделенного соединения клиент-сервер. Однако не все задачи в мире удобно и возможно решать таким способом. Кроме очень известных API, приведу пару примеров другого типа из своего опыта:
— Сервис о футболе. Примеры функций: получить текущие матчи, матчи на дату, результаты прошедших матчей, детали матча по id, занести/изменить информацию о матче.
— Сервис с букмекерскими ставками. Функции: получить текущие ставки, получить активные букмекерские конторы, ставки по маркеты, ставки на матч.
— Сервис новостей. get/create/edit/delete новость, список новостей по категории, добавление комментариев.
Да что угодно!
Я вряд ли смогу повлять на Ваш взгляд на REST сервисы, но мне кажется, что вы объединяете понятие сайта и сервиса/клиента сервиса. Мне так кажется из-за ваших слов о viewstate. Клиентом сервиса может быть не только сайт, а что угодно, что умеет вызывать url и понимать ответ в xml или json.
Вы писали: «Взять любую мало мальски серьезную задачу, она всегда имеет пошаговую этапность, например покупка товаров в интернет магазине имеет состояние — корзину; а когда взаимодействует одно финансовое приложение с другим, имеет состояние — транзакцию, и на N-том шаге (вызове) мы можем понять, что нужно откатить всю транзакцию;»
Архитектура REST никак не ограничивает нас в плане имплементации. Где сделать все проверки — наше дело. Вы можете вообще не вызывать сервис, пока покупка не будет завершена, тогда будете сами ответственны за откат транзакции.
А можете вызывать пошагово что-то вроде
create order
create paymentProcess
успешно оплатил
edit oder/ set status=completed
delete paymentProcess/id
и т.д.
И тогда при падении на любой стадии сможете все отседить.
В случае транзакций вообще лучше использовать SOAP.
Прямым соединением через сокеты всех проблем не решить, ресурсов не хватит. Не говоря уже о сложности внесения изменений в работу сервиса.
MarcusAurelius, я думаю, Вы не врете, что прочитали много всего по данному вопросу, просто у Вас совершенно другое восприятие, я бы сказал альтернативное восприятие.
Вы явно больше сталкивались с задачами, где удобнее работать через сокеты с установлением выделенного соединения клиент-сервер. Однако не все задачи в мире удобно и возможно решать таким способом. Кроме очень известных API, приведу пару примеров другого типа из своего опыта:
— Сервис о футболе. Примеры функций: получить текущие матчи, матчи на дату, результаты прошедших матчей, детали матча по id, занести/изменить информацию о матче.
— Сервис с букмекерскими ставками. Функции: получить текущие ставки, получить активные букмекерские конторы, ставки по маркеты, ставки на матч.
— Сервис новостей. get/create/edit/delete новость, список новостей по категории, добавление комментариев.
Да что угодно!
Я вряд ли смогу повлять на Ваш взгляд на REST сервисы, но мне кажется, что вы объединяете понятие сайта и сервиса/клиента сервиса. Мне так кажется из-за ваших слов о viewstate. Клиентом сервиса может быть не только сайт, а что угодно, что умеет вызывать url и понимать ответ в xml или json.
Вы писали: «Взять любую мало мальски серьезную задачу, она всегда имеет пошаговую этапность, например покупка товаров в интернет магазине имеет состояние — корзину; а когда взаимодействует одно финансовое приложение с другим, имеет состояние — транзакцию, и на N-том шаге (вызове) мы можем понять, что нужно откатить всю транзакцию;»
Архитектура REST никак не ограничивает нас в плане имплементации. Где сделать все проверки — наше дело. Вы можете вообще не вызывать сервис, пока покупка не будет завершена, тогда будете сами ответственны за откат транзакции.
А можете вызывать пошагово что-то вроде
create order
create paymentProcess
успешно оплатил
edit oder/ set status=completed
delete paymentProcess/id
и т.д.
И тогда при падении на любой стадии сможете все отседить.
В случае транзакций вообще лучше использовать SOAP.
Прямым соединением через сокеты всех проблем не решить, ресурсов не хватит. Не говоря уже о сложности внесения изменений в работу сервиса.
> Вы писали: «Взять любую мало мальски серьезную задачу, она всегда имеет пошаговую этапность
Самое смешное, что это на это я уже отвечал тут и цитировал тут :)
Но у человека явно проблема с непониманием процесса, потому что он считает, что «2. Динамический контент- без перезагрузки страницы, по времени и по событиям перегружаются блоки, оперативно реагируя на состояние сервера в целом и на состояние клиентов» — это, видаь, магия :)
Самое смешное, что это на это я уже отвечал тут и цитировал тут :)
Но у человека явно проблема с непониманием процесса, потому что он считает, что «2. Динамический контент- без перезагрузки страницы, по времени и по событиям перегружаются блоки, оперативно реагируя на состояние сервера в целом и на состояние клиентов» — это, видаь, магия :)
в ответ на сообщение MarcusAurelius:
1. Да, я сравниваю архитектурный стиль с семейством протоколов, однако имею на это полное право — сравниваю их как варианты решения одной и той же задачи (интеграция приложений) для программиста. Статью я пытался сделать максимально практической, без теоретических сюси-пуси. Я пытаюсь ответить на вопрос «Какой способ взаимодействия разных платформ проще и эффективнее на практике?». Надо переименовать статью… Вы не правильно поняли даже после смущения — под REST я имею в виду именно REST, можете прочитать на википедии про REST, я именно это и имел в виду.
2. Благодаря этой «ущербности» сервисы REST отлично масштабируются и поддерживают кеширование. Поэтому мне кажется, нужно говорить о том, что для одних задач лучше подойдет REST, для других SOAP, а для третьих — прямое соединение по сокетам. Думаю, читателям и мне было бы интересно, если Вы привели бы пару примеров из своего опыта.
1. Да, я сравниваю архитектурный стиль с семейством протоколов, однако имею на это полное право — сравниваю их как варианты решения одной и той же задачи (интеграция приложений) для программиста. Статью я пытался сделать максимально практической, без теоретических сюси-пуси. Я пытаюсь ответить на вопрос «Какой способ взаимодействия разных платформ проще и эффективнее на практике?». Надо переименовать статью… Вы не правильно поняли даже после смущения — под REST я имею в виду именно REST, можете прочитать на википедии про REST, я именно это и имел в виду.
2. Благодаря этой «ущербности» сервисы REST отлично масштабируются и поддерживают кеширование. Поэтому мне кажется, нужно говорить о том, что для одних задач лучше подойдет REST, для других SOAP, а для третьих — прямое соединение по сокетам. Думаю, читателям и мне было бы интересно, если Вы привели бы пару примеров из своего опыта.
И теоретически и практически SOAP является надстройкой над одной из реализаций REST, а именно, над HTTP протоколом. Поэтому сравнивать их — все равно, что сравнивать, что Вам больше нравится «икра» или «черная икра», т.е. это понятия разного уровня абстракции. Первая Ваша статья очень четкая и технологичная, тут же, Вы явно запутались в понятиях. С чем я безоговорочно согласен в ваших рассуждениях, так это с тем, что для каждой задачи есть вариант сетевого взаимодействия, который наиболее к нему подходит, и напротив — одного решения, подходящего для всех задач, существовать не может.
Рад, что Вам понравилась первая статья.
Там я писал с теоретическо-технологической точки зрения, здесь же пишу с практической, поэтому и заостряю внимаю на других вещах.
SOAP не является одной из реализаций REST!!! Он не выполняет 4 из 5 основных принципов REST!
Если посмотрите в первую часть статьи, то выполняется только принцип 1.
Почему SOAP не REST:
Use standard methods — нет. Запросы происходят только через HTTP POST (В SOAP 1.2 описана поддержка GET, но на практике ее нет).
Resources can have multiple representations — нет, только конверт SOAP.
Communicate statelessly — опять нет.
Link things together — тоже нет, взаимодействие чисто по заданному интерфейсу.
Там я писал с теоретическо-технологической точки зрения, здесь же пишу с практической, поэтому и заостряю внимаю на других вещах.
SOAP не является одной из реализаций REST!!! Он не выполняет 4 из 5 основных принципов REST!
Если посмотрите в первую часть статьи, то выполняется только принцип 1.
Почему SOAP не REST:
Use standard methods — нет. Запросы происходят только через HTTP POST (В SOAP 1.2 описана поддержка GET, но на практике ее нет).
Resources can have multiple representations — нет, только конверт SOAP.
Communicate statelessly — опять нет.
Link things together — тоже нет, взаимодействие чисто по заданному интерфейсу.
Теперь по поводу прокси: это не единственный способ быстрой разработки межпроцессовгого взаимодействия, поверьте, в 1997-1999 годах, когда SOAP было предпринято множество малых и больших разработок в этом направлении, а XML-RPC и SOAP не лучшие из них, конечно это было прорывом по сравнению с бывшими тогда в широкм хождении технологиями CORBA (Common Object Request Broker) и DCOM (Distributed Component Object Model). Все они генерировали прокси или в виде интерфейсов или в виде классов, но сложности разработки и внедрению CORBA и DCOM были сложнее специализированных протоколов, плюс постоянные танцы с бубном, чтобы что-то запустилось и «dll hell». Но жить то как-то нужно и быстро разрабатывать приложения нужно, у людей сроки, не до концептуального булшита, ну в общем, и на C++ и Delphi были разработаны множества альтернативных вариантов, генерирующих прокси. Я лично написал свой, и работал он так, что и сейчас в .Net гораздо сложнее и дольше писать. Представьте Delphi или C++ Builder, делаем форму, называем ее например «TicketBooking» кладем на нее несколько невизуальных контролов типа TuspFunction и называем их «ListTickets», «CheckTicketAvailability», «BookTicket», двойным щелчком на каждом контроле переходим к написанию тела процедуры, сервер готов, из клиента видим интерфейс с тремя методами. А еще на клиенте ставим контролы класса TuspEvent и имеем возможность серверные события транслировать на клеинт. Вся разработка заняла менее 1 месяца, кода 98кб всего, я уже не видел сего вело-костыля более 7 лет, но до сих под на нем не только работают крупные системы, но и люди его в разработке используют. Я не говорю, что это я что-то гениальное изобрел, я видел множество аналогов, сложнее и проще, узко специализированных и универсальных, в те времена программисты не боялись программировать, поэтому была какая-то альтернатива, сейчас же весь технологический стек хоть и более стандартизирован, но не проще в разработке, не гибче и не поддерживает даже самого основного: двухстороннего асинхронного взаимодействия с установлением соединения и машиной состояний.
К сожалению, про то, что Вы именно написали на плюсах, я не совсем понял. Но я и не писал на плюсах никогда, так что другие должны понять.
Но хочу спросить другое. Почему вы думаете, что двухстороннее асинхронное взаимодействие с установлением соединения и машиной состояний — это самое важное?
В общем случае сервис предоставляет какие-то данные или выполняют какую-то бизнес-операцию, зачем асинхронность? и состояния далеко не всегда нужны, вроде бы как.
Но хочу спросить другое. Почему вы думаете, что двухстороннее асинхронное взаимодействие с установлением соединения и машиной состояний — это самое важное?
В общем случае сервис предоставляет какие-то данные или выполняют какую-то бизнес-операцию, зачем асинхронность? и состояния далеко не всегда нужны, вроде бы как.
Это, вроде как, самое универсальное. Любую другую необходимую модель можно реализовать на этой базе.
Взять любую мало мальски серьезную задачу, она всегда имеет пошаговую этапность, например покупка товаров в интернет магазине имеет состояние — корзину; а когда взаимодействует одно финансовое приложение с другим, имеет состояние — транзакцию, и на N-том шаге (вызове) мы можем понять, что нужно откатить всю транзакцию; заказ билетов на самолет тоже пошаговое, если заказывает пользователь (он сначала зарегистрируется, потом укажет откуда и куда, потом выберет места, это диалог), а если заказывает одна программа у другой, то тоже нужно состояние (например, сначала места резервируются и приходит ответ о том, что они заблокированы на какое-то время и уже после этого покупающая система проводит электронную оплату, взаимодействую с третьей системой — платежной, потом нужно уведомить, продающую сторону о том, что платеж ушел, продающая система проверяет пришел ли платеж и тогда уже отвечает покупающей стороне о том, что покупка успешна). Да где угодно нужно состояние.
А что я говорю об «асинхронном взаимодействии с установлением соединения и машиной состояний» — это не самое важное, но сейчас все движется к интерактивным системам, когда пользовательский экран постоянно меняется в зависимости от его собственных действий, событий на сервере, действий других пользователей и т.д. Посмотрите Gmail, Google Documents, Facebook, Amazon, да что угодно, это полностью живые и дышащие системы, постоянно обменивающиеся сообщениями, но пока еще им приходится использовать костыли в виде LONG POOLING, но все больше приходят веб-сокеты для клиент-серверного взаимодействия, а между серверами уже давно сокеты живут. Из HTTP уже выжаты все возможности, он уже стал частично интерактивным протоколом, что противоречит его природе, но вот уже и этого мало, HTTP тоже отойдет в сторону, скоро нужно будет делать множество мобильных приложений разнообразных, социальной направленности, для бизнеса, общения, торговли, а на мобильной платформе трафик дорогой и медленный, а LONG POOLING плохо вообще работает из-за менее стабильной и непостоянной связи. Сокетные соединения опять будут в ходу, только стандартизация тут конечно нужно, это не дело, чтобы выдумывали свое, нужно несколько типовых решений, какие-то более гибкие и более сложные, а какие-то более простые и менее продвинутые.
А что я говорю об «асинхронном взаимодействии с установлением соединения и машиной состояний» — это не самое важное, но сейчас все движется к интерактивным системам, когда пользовательский экран постоянно меняется в зависимости от его собственных действий, событий на сервере, действий других пользователей и т.д. Посмотрите Gmail, Google Documents, Facebook, Amazon, да что угодно, это полностью живые и дышащие системы, постоянно обменивающиеся сообщениями, но пока еще им приходится использовать костыли в виде LONG POOLING, но все больше приходят веб-сокеты для клиент-серверного взаимодействия, а между серверами уже давно сокеты живут. Из HTTP уже выжаты все возможности, он уже стал частично интерактивным протоколом, что противоречит его природе, но вот уже и этого мало, HTTP тоже отойдет в сторону, скоро нужно будет делать множество мобильных приложений разнообразных, социальной направленности, для бизнеса, общения, торговли, а на мобильной платформе трафик дорогой и медленный, а LONG POOLING плохо вообще работает из-за менее стабильной и непостоянной связи. Сокетные соединения опять будут в ходу, только стандартизация тут конечно нужно, это не дело, чтобы выдумывали свое, нужно несколько типовых решений, какие-то более гибкие и более сложные, а какие-то более простые и менее продвинутые.
У меня вопрос ко всем, на который я сам не могу ответить.
Есть ли такие задачи, с которыми SOAP справляется отлично, а REST или справляется хуже, или вообще не справляется? Не могу придумать пример.
Есть ли такие задачи, с которыми SOAP справляется отлично, а REST или справляется хуже, или вообще не справляется? Не могу придумать пример.
В чистом виде, без сессий, REST вообще не имеет ни одного приложения кроме статических страниц, хотя бы потому, что cookies нужны для идентификации пользователя, ну не автентифицировать же его при каждом вызове. Или же Вам придется тягать за собой viewstate, как это было в ASP, но благо — одумались и теперь viewstate уже везде «вне закона». Лучше сравнивайте голый HTTP и SOAP. Под HTTP тут можно понимать запрос к определенному URL, представляющему API, который понимает определенный набор параметров в POST запросе, обязательно использующий механизм сессий и возвращающий данные в заранее оговоренном формате, например JSON или XML. Вот что можно и нужно сравнить: SOAP, голый HTTP (можно подразумевать тут AJAX/JSON) и сокеты.
В чистом виде, без сессий, REST вообще не имеет ни одного приложения кроме статических страниц, хотя бы потому, что cookies нужны для идентификации пользователя, ну не автентифицировать же его при каждом вызове.
Обсуждалось в первой части статьи. REST не запрещает использовать authentication cookie.
Обсуждалось в первой части статьи. REST не запрещает использовать authentication cookie.
Если есть cookies, то есть сессия, если есть сессия значит есть состояние (пусть оно хранит только несколько переменных), если есть состояние, то это уже не REST в систом виде.
Куки и сессия вещи не пересекающиеся, кроме того случая, когда в куках мы храним ид сессии. Если состояние хранится в куках, то это вполне нормальный REST. При запросе куки такой же параметр как GET или POST параметры, а при ответе такой же ответ как тело. Запрос на аутентификацию создает куку с (зашифрованным) id пользователя — сессий в чистом виде нет, между запросами никакие данные на сервере не хранятся, кроме явных запросов на создание/изменение ресурсов. Если понятие ресурса немного расширить от простой записи в БД, которую можно получить по GET, то и с сессиями приложение может считаться RESTful. Процедуру авторизации (логина) называем просто созданием ресурса, процедуру выхода (логоффа) — уничтожением ресурса, различные многошаговые операции, типа покупки в магазине через корзину — редактированием этого ресурса. Если не заботиться о ЧПУ, а заботиться о максимальном соотвествии REST, то логин у нас будет POST /session, логофф DELETE /session, шаги по покупке (кроме последнего) PUT /session.
А чем тогда ресурс отличается от состояния?
Тем, что, например, текущая страница — это ресурс, а не состояние.
Тогда ничем :) Состояние такой же ресурс, как и остальные модели, только идентифицируется не в урле, а кукой. А если брать глобально, то состояние приложения это «снимок» всех его данных, включая ресурсы. Так или иначе, но вряд ли в более-менее нормальном приложении ресурсы не будут «скрытно» взаимодействовать между собой, почему бы не вписать в это взаимодействие и сессии.
Такс, пришли в терминологический тупик )))
Идентификация пользователя возможно по ключу в GET — параметре.
> поддержка SOAP платформами
О чем вообще эта таблица? Библиотеки для реализации SOAP есть для любго мейнстримного языка и платформы.
О чем вообще эта таблица? Библиотеки для реализации SOAP есть для любго мейнстримного языка и платформы.
как насчет Objective-C?
Кустарные библиотеки не в счет.
Кустарные библиотеки не в счет.
Sign up to leave a comment.
REST vs SOAP. Часть 2. Как проще и эффективнее организовать общение платформ?