>Почему у меня на работе они есть? ;) Да, их пришлось написать самостоятельно, но это не так много кода.
>Что мешает адаптировать эти или похожие инструменты к REST'у? ;)
думаю, можно вывести общую мысль о том, что надо анализировать каждую задачу отдельно чтобы определить наиболее подходящий вариант взаимодействия.
Иногда SOAP может многократно ускорить процесс разработки, однако часто — нет. Думаю, мы все понимаем почему.
Согласен с png, интересно узнать про инструменты на Вашей работе) на чем написаны, что делают, насколько универсальны?
У меня у друга на проекте они должны из .Net юзать REST сервис, возвращающий довольно накрученные объекты. Они хорошо подумали, как лучше реализовать задачу, и решили делать это с помощью вручную написанных классов с расставленными аттрибутами сериализации. Запросы посылают через HttpClient, ответ десериализуют каким-то json-сериалайзером. Вроде бы достаточно просто и красиво, но все же полная автоматизация.
> Не надо рассказывать сказки. Ничего SOAP не делает автоматически. Вернее, не более автоматически чем любая другая компьютерная фигня. Если вы про валидацию по DTD/Schema, что что мешает иметь ее для REST?
>> то с SOAP конечно легче — он сам найдет все изменеия структуры сообщений и внесет поправки.
>С какого перепугу он найдет это сам? И что мешает сделать такое же для REST?
В обоих каментах я имею в виду, что генерация прокси сделает за нас всю работу — и не позволит передать/получить не тот тип, и в случае измений на сервере позволит перегенерить клиента.
если я правильно понял, что такое версионность, то с SOAP конечно легче — он сам найдет все изменеия структуры сообщений и внесет поправки. С REST все вручную
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.
Прямым соединением через сокеты всех проблем не решить, ресурсов не хватит. Не говоря уже о сложности внесения изменений в работу сервиса.
В чистом виде, без сессий, REST вообще не имеет ни одного приложения кроме статических страниц, хотя бы потому, что cookies нужны для идентификации пользователя, ну не автентифицировать же его при каждом вызове.
Обсуждалось в первой части статьи. REST не запрещает использовать authentication cookie.
Рад, что Вам понравилась первая статья.
Там я писал с теоретическо-технологической точки зрения, здесь же пишу с практической, поэтому и заостряю внимаю на других вещах.
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 на JAVA? ) вроде бы сейчас уже нормальная его поддержка есть
«Сгенерировать REST-клиента на WCF тоже можно». Как? Самое лучшее, что я нашел — это WCF REST starter kit, который был написан под .Net framework 3.5, в 4 уже были внедрены некоторые его фичи, а в 4.5 фреймверк, я так понял, он будет полностью встроен.
В этом WCF REST starter kit есть удобные фичи, но это все же не полноценная генерация прокси.
К сожалению, про то, что Вы именно написали на плюсах, я не совсем понял. Но я и не писал на плюсах никогда, так что другие должны понять.
Но хочу спросить другое. Почему вы думаете, что двухстороннее асинхронное взаимодействие с установлением соединения и машиной состояний — это самое важное?
В общем случае сервис предоставляет какие-то данные или выполняют какую-то бизнес-операцию, зачем асинхронность? и состояния далеко не всегда нужны, вроде бы как.
1. Да, я сравниваю архитектурный стиль с семейством протоколов, однако имею на это полное право — сравниваю их как варианты решения одной и той же задачи (интеграция приложений) для программиста. Статью я пытался сделать максимально практической, без теоретических сюси-пуси. Я пытаюсь ответить на вопрос «Какой способ взаимодействия разных платформ проще и эффективнее на практике?». Надо переименовать статью… Вы не правильно поняли даже после смущения — под REST я имею в виду именно REST, можете прочитать на википедии про REST, я именно это и имел в виду.
2. Благодаря этой «ущербности» сервисы REST отлично масштабируются и поддерживают кеширование. Поэтому мне кажется, нужно говорить о том, что для одних задач лучше подойдет REST, для других SOAP, а для третьих — прямое соединение по сокетам. Думаю, читателям и мне было бы интересно, если Вы привели бы пару примеров из своего опыта.
«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/
А вообще ведь действительно это возможно стандартизировать, я об этом сначала даже и не подумал.
>Что мешает адаптировать эти или похожие инструменты к REST'у? ;)
думаю, можно вывести общую мысль о том, что надо анализировать каждую задачу отдельно чтобы определить наиболее подходящий вариант взаимодействия.
Иногда SOAP может многократно ускорить процесс разработки, однако часто — нет. Думаю, мы все понимаем почему.
Согласен с png, интересно узнать про инструменты на Вашей работе) на чем написаны, что делают, насколько универсальны?
У меня у друга на проекте они должны из .Net юзать REST сервис, возвращающий довольно накрученные объекты. Они хорошо подумали, как лучше реализовать задачу, и решили делать это с помощью вручную написанных классов с расставленными аттрибутами сериализации. Запросы посылают через HttpClient, ответ десериализуют каким-то json-сериалайзером. Вроде бы достаточно просто и красиво, но все же полная автоматизация.
Я не прав?
>> то с SOAP конечно легче — он сам найдет все изменеия структуры сообщений и внесет поправки.
>С какого перепугу он найдет это сам? И что мешает сделать такое же для REST?
В обоих каментах я имею в виду, что генерация прокси сделает за нас всю работу — и не позволит передать/получить не тот тип, и в случае измений на сервере позволит перегенерить клиента.
Кустарная — это та, которая не справляется с задачей, глючит и т.п.
Таблицу дополню.
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.
Прямым соединением через сокеты всех проблем не решить, ресурсов не хватит. Не говоря уже о сложности внесения изменений в работу сервиса.
Обсуждалось в первой части статьи. REST не запрещает использовать authentication cookie.
Там я писал с теоретическо-технологической точки зрения, здесь же пишу с практической, поэтому и заостряю внимаю на других вещах.
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 — тоже нет, взаимодействие чисто по заданному интерфейсу.
Кустарные библиотеки не в счет.
В REST же сервис не имеет состояния — это один из принципов, описанных Филдингом.
«Сгенерировать REST-клиента на WCF тоже можно». Как? Самое лучшее, что я нашел — это WCF REST starter kit, который был написан под .Net framework 3.5, в 4 уже были внедрены некоторые его фичи, а в 4.5 фреймверк, я так понял, он будет полностью встроен.
В этом WCF REST starter kit есть удобные фичи, но это все же не полноценная генерация прокси.
Есть ли такие задачи, с которыми SOAP справляется отлично, а REST или справляется хуже, или вообще не справляется? Не могу придумать пример.
Но хочу спросить другое. Почему вы думаете, что двухстороннее асинхронное взаимодействие с установлением соединения и машиной состояний — это самое важное?
В общем случае сервис предоставляет какие-то данные или выполняют какую-то бизнес-операцию, зачем асинхронность? и состояния далеко не всегда нужны, вроде бы как.
Он хранится в кукисах и пересылается при каждом запросе к серверу.
1. Да, я сравниваю архитектурный стиль с семейством протоколов, однако имею на это полное право — сравниваю их как варианты решения одной и той же задачи (интеграция приложений) для программиста. Статью я пытался сделать максимально практической, без теоретических сюси-пуси. Я пытаюсь ответить на вопрос «Какой способ взаимодействия разных платформ проще и эффективнее на практике?». Надо переименовать статью… Вы не правильно поняли даже после смущения — под REST я имею в виду именно REST, можете прочитать на википедии про REST, я именно это и имел в виду.
2. Благодаря этой «ущербности» сервисы REST отлично масштабируются и поддерживают кеширование. Поэтому мне кажется, нужно говорить о том, что для одних задач лучше подойдет REST, для других SOAP, а для третьих — прямое соединение по сокетам. Думаю, читателям и мне было бы интересно, если Вы привели бы пару примеров из своего опыта.