REST — гибкость. структуру документа мы пишем сами. валидаторы пишем сами. парсеры пишем сами. Генерацию XML тоже пишем сами. Сервер тоже пишем сами (роутинг запросов по HTTP, обработка параметров и т.п.).
В каждом языке правда есть средства, которые этот процесс частично упрощают. Но итог, остается один. мы дофига всего пишем сами. А то, что мы пишем сами, нужно проверять.
SOAP — это жесткий протокол. На него написаны уже валидаторы. Написаны схемы данных. Написаны клиенты и сервера.
мы просто описываем объект который хотим послать и канал(фактически запрос, или если хотите функция с параметрами и возвращаемым типом), по которому будем слать.
Параметры и возвращаемый тип — это объекты, которые по косточкам разбираются на элементарные типы.
Итог, мы описываем только структуру данных как объект или группу объектов, остальная работа делается за нас и отдается на откуп клиенту и серверу SOAP.
Делать какие-то ещё проверки бессмыслено, т.к. они уже сделаны. достаточно проверить, что данные пришли те и всё.
Ошибки и в клиенте-сервере SOAP могут быть. Но это ошибки сторонней библиотеки. Про них можно написать в баг репорт. Или вообще уйти на другую библиотеку.
А поскольку этим софтом много кто пользуется, то % ошибок там существенно меньше, чем в вашем коде. В любом случае, вы за него не отвечаете.
Там фраза вырванная из контекста. Речь шла о другом. о том, что данные в стандартном формате, а значит их можно легко обрабатывать. В шоколаде значит, что подход реально удобен по сравнению с SOAP, если ты публикуешь сервис наружу.
А далее, я говорю, что при обработке могут быть допущены ошибки, этот момент нужно тоже не упустить.
Лично я не считаю, что SOAP хорош для публикации наружу. Бывают проблемы с разными клиентами. Так что для каждой задачи свое.
Изначально у меня речь не шла только об изменениях структуры. И без этого есть где косячить, но всё же в ответ на:
А почему оно должно отвалиться, и почему оно не отвалится при неREST'е?
ИХМО проверять лучше структуру, а не данные.
можно подобрать ситуацию, когда при некотором изменении структуры первые 1000 XML-к будут валидны по старому валидатуру, а 1001 первый стал не валиден.
И как это ловить?
Иногда оно всплывает через месяц, иногда через год. У меня было через пару месяцев, под конец проекта(проект был на 3-4 месяца). Пришлось попотеть, чтобы успеть. Да и понервничать.
Объяснения к этому: «если структура сообщений поменяется (или мы в ней сделали ошибку), мы 100 лет будет искать ошибку» так и не было ;)
было. Возможно немного невнятно.
Вот оно
А теперь про ошибку, если я беру данные с какого-либо REST-сервиса, то по-хорошему нужно проверять, а правильно ли я их беру. Эту проверку осуществляет клиент, а не сервер.
Для REST вам придется писать её руками, или не писать, но при этом придется больше внимания уделить тестированию (никто не даст гарантии, что при очередном рефакторинге у вас чего-нибудь не отвалится)
поясняю чуть по подробней:
Допустим у нас клиент, который читает данные с REST сервиса.
Допустим вы в парсере допустили ошибку. тег не так назвали. поставили лишнюю букву или пропустили. Или перепутали два тега в процессе разработки копипастом. Итог, данные в объекте либо пустые, либо не те.
Если пустые, то бывает иногда что-нибудь отвалится, а если не те — то это вообще сложно ловить. Я такие вещи ловил юнит тестами, если этого нет, то такой косяк можно поймать:
— внимательными глазами разработчика, который делает вам Code Review (или вы сами проверяли, увидели, так тоже бывает).
— внимательными глазами тестера, который будет сравнивать вход-выход
А может случиться так, что никогда не поймаете. Всплывает уже в процессе эксплуатации через какое-то время.
Они хорошо подумали, как лучше реализовать задачу, и решили делать это с помощью вручную написанных классов с расставленными аттрибутами сериализации. Запросы посылают через HttpClient, ответ десериализуют каким-то json-сериалайзером. Вроде бы достаточно просто и красиво, но все же полная автоматизация.
Я тоже так делал, только в Java. К тому же ответ тоже можно десериализовать в объект по тем же аннотациям. То есть этот фокус в обе стороны работает. К тому же, легко покрывается тестами.
Проблема в том, что эти объекты пришлось руками описывать. Использовать WADL не вышло, сторонний сервис его не предоставлял.
Проблема не в инструментах. Такие инструменты есть. Можно генерить код из WADL в той же idea от JetBrains.
Проблема 1, это работает только для Javа клиентов. В динамических языках всё динамическое. Поэтому если сильно хочется, прокси придется делать самому.
Идеология SOAP уже говорит, что нужно проверять данные. Поэтому все клиенты SOAP как-то реализуют поддержку валидации, без нее же ничего работать не будет.
Проблема 2, чтобы генерить прокси для REST, нужно сначала иметь файл WADL для этого сервиса. Я пока ещё не видел ни одного популярного сервиса REST, который бы предоставлял WADL файл(скажите мне, если найдете такой, попробую погенирить для него прокси на java, интересно, будет ли вообще работать).
Скорее наоборот, часто разработчики совсем отходят в сторону от REST(когда по одному урлу доступно несколько разных типов объектов с одной шапкой и разными данными внутри).
>>С какого перепугу он найдет это сам? И что мешает сделать такое же для REST?
если формат данных будет не такой, как WSDL, то обмен данными просто не будет работать. Это и называется, он сам найдет.
Для REST такое тоже есть WADL, но проблема в том, что многие разработчики считают, что он не укладывается в архитектуру REST и потому он не нужен.
А кому-то просто лень реализовывать генерацию ещё одной XML, которая только всё усложняет.
>>Не будете. Версионность для REST-сервисо тоже никто не отменял
Буду, но не там, где вы думаете.
простите, похоже вы не так поняли то, что я имел в виду.
Я не за, и не против REST. Более того, в предпоследнем проекте делал обмен на REST, в последнем на SOAP. Поэтому у меня сложилось свое мнение относительно этих двух идей реализаций обмена данными.
Вариант первый. Вы пишите сервер, клиенты пишут все остальные. Главное, не вы. К тому же, клиентов туча и они разношерстные (разные языки, платформы и т.п.).
Тут я думаю лучше использовать REST. Плюс в том, что отдаются данные в каком-нибудь стандартном формате. Например, XML. Добавляем сюда весь богатый инструментарий по валидации этих данных — и всё в шоколаде. Главное вы отдаете данные правильно. Остальное вас не касается. Пример, Twitter и тому подобное.
Тут нареканий нет, очень удобная и гибкая архитектура.
SOAP же в этом случае применять не очень удобно, т.к. будет много накладных проблем с разными версиями SOAP а так же с особенностями реализации клиента SOAP на каждой из платформ.
Вариант второй, и клиент, и сервер ваши. Вам нужно передать объект А от сервера к клиенту или наоборот. В этом случае SOAP дает решение из коробки. Поднимаем сервер, описываем объект и у нас всё работает.
А теперь про ошибку, если я беру данные с какого-либо REST-сервиса, то по-хорошему нужно проверять, а правильно ли я их беру. Эту проверку осуществляет клиент, а не сервер.
Для REST вам придется писать её руками, или не писать, но при этом придется больше внимания уделить тестированию (никто не даст гарантии, что при очередном рефакторинге у вас чего-нибудь не отвалится).
С точки зрения теории можно любую задачу раскидать на объекты.
Объекты нужно создавать, задавать им параметры, получать их данные.
Далее объекты = ресурсы. и тогда к ним можно применять идеологию REST.
Получается достаточно красиво. А теперь пример задачи на вскидку.
Есть сервис, которого можно попросить удаленно что-нибудь сделать.
Пусть он всё делает в фоне.
схема общения такая, создаем задачу, запоминаем её ID.
Ждем, спрашиваем не готово ли. (можно и не ждать, а ожидать какого-либо события, переданного как-то, но не в этом суть, пусть для простоты будет так)
Получаем по ID результат.
Казалось бы, очень красиво всё ложится в REST.
Пишем ресурс задачи. Создание её, получение данных и т.п.
Дошли до клиента. выходит — нужно писать логику, сформировать XML(JSON), отослать, получить назад XML(JSON) обработать.
сформировать урл для получения данных для задачи. опять послать запрос, получить результат распарсить.
Если пишем на Java, то можно красиво смапить XML в объекты(хотя и). На других языках получается всё менее красиво, слишком много телодвижений.
Главный для меня минус, если структура сообщений поменяется (или мы в ней сделали ошибку), мы 100 лет будет искать ошибку. Как проверять скопировались данные или нет — тоже не понятно. Лучший способ, покрыть обильно данный код тестами. в итоге получается такая жирненькая задачка.
Пишем аналог на SOAP. Описываем сервис, он должен обмениваться объектами. Создаем задачу вызовом одного метода. получаем результат вызовом другого метода. Если результат получен — сразу у нас в программе объект с данными(если язык это поддерживает).
никаких XML, никакого парсинга. Нужно добиться чтобы версии SOAP совпадали и клиенты их правильно поддерживали.
Трудоемкость такой задачи на порядок меньше. Плюс контроль данных, которые приходят.
Итог, задача красиво ложится на REST архитектуру, а в SOAP её проще и быстрее реализовать по трудоемкости. Т.к. SOAP берет часть работы по валидации данных на себя. За счет этого оно и проще.
Проблему частично решает WADL. Но, генераторы кода клиента есть только на Java.
Итог для меня, простые вещи без какой-то особой логики можно реализовывать на REST.
Клиент пишется в 2 строчки, особой валидации не нужно и т.п.
Когда система усложняется, то нужно уже думать — как оно лучше, удобней и проще реализовать.
У меня тоже были проблемы с программистом, который воспринимал любую критику негативно.
Думаю, либо у человека дома не всё в порядке, либо работой перегружен, что просто срывается. Такого в отпуск срочно, пусть проспится, а потом решит свои домашние проблемы.
Первое. Конструктивный диалог иногда помогает. Мы же взрослые люди.
Второе. В каждом проекте есть соглашения разработки. Разработчик должен делать так, как принято в проекте, а не так, как ему хочется. Те или иные решения принимались не из-за хорошей жизни. А если они прижились, что значит они работают. А иначе всё будет — как в басне Крылова про 3-х животных. Если кто-то не следует соглашениям, то с этим тоже нужно что-то делать. Например, бить по рукам… :( но это уже крайний вариант
Статья очень понравилась. Большое спасибо автору.
В ответ на:
«Очень хотелось бы услышать от уважаемых хабраграждан, как бороться с микроменеджментом в полевых условиях силами разработчиков. Особенно интересуют случаи успешной борьбы.»
Конструктивный диалог и предложение более качественных решений позволяют побороть это явление.
«управляющий» (если он адекватен) видит, что человек в теме, и дает подчиненному свободу решать задачу по его схеме.
Побывал в обоих ролях. Мне удавалось доказывать, свое мнение. И мне тоже доказывали мнение те, кем мне доводилось руководить. Так происходит потому, что человек решающий задачу на месте в самой задаче ориентируется лучше(если, конечно, он не начинающий, или просто новый человек в проекте, или ещё хуже — быдлокодер), чем руководитель.
А теперь позволю себе оставить свое мнение по поводу микроменеджмента:
я думаю, что он необходим только в одном случае — как одно из средств для обучения.
Я делал так:
сначала давал повозиться человеку в своем коде и документации 1-2 дня; пусть сам разберется;
если не разобрался, давал ссылки на документацию, литературу и на примеры — как нужно.
если и это не помогло, то корректировал решение сам, либо часть решения, объяснял как нужно и почему так, заставлял доделать — как нужно; возможно на это уходило несколько итераций
Далее следующая задача по той же схеме. После нескольких задач человек растет быстрее, и достаточно просто проглядывать его код на явные косяки.
Пару раз схема не срабатывала. В проекте было много новичков, не хватало времени работать с каждым. Да и объясняю я не очень понятно. В итоге, быдлокод был жутким… Но к концу проекта народ стал писать по лучше.
ну тут смотря как рубиться.
у нас тоже на работе есть настольный тенис.
одна-две партейки раз в 3 часа позволяет размяться и прочистить мозги.
А если в это время ещё и проветриваем помещение, то можно играть и двое на двое.
Спасибо за ответ.
В каждом языке правда есть средства, которые этот процесс частично упрощают. Но итог, остается один. мы дофига всего пишем сами. А то, что мы пишем сами, нужно проверять.
SOAP — это жесткий протокол. На него написаны уже валидаторы. Написаны схемы данных. Написаны клиенты и сервера.
мы просто описываем объект который хотим послать и канал(фактически запрос, или если хотите функция с параметрами и возвращаемым типом), по которому будем слать.
Параметры и возвращаемый тип — это объекты, которые по косточкам разбираются на элементарные типы.
Итог, мы описываем только структуру данных как объект или группу объектов, остальная работа делается за нас и отдается на откуп клиенту и серверу SOAP.
Делать какие-то ещё проверки бессмыслено, т.к. они уже сделаны. достаточно проверить, что данные пришли те и всё.
Ошибки и в клиенте-сервере SOAP могут быть. Но это ошибки сторонней библиотеки. Про них можно написать в баг репорт. Или вообще уйти на другую библиотеку.
А поскольку этим софтом много кто пользуется, то % ошибок там существенно меньше, чем в вашем коде. В любом случае, вы за него не отвечаете.
Про это никто не спорит, вопрос о том, как проверять. Какова трудоемкость этих проверок.
у SOAP тоже бывают проблемы, и что…
Идеология-идеологией. но в конце-концов будет программный продукт. Если что-то не работает, это приходится как-то решать…
А далее, я говорю, что при обработке могут быть допущены ошибки, этот момент нужно тоже не упустить.
Лично я не считаю, что SOAP хорош для публикации наружу. Бывают проблемы с разными клиентами. Так что для каждой задачи свое.
ИХМО проверять лучше структуру, а не данные.
можно подобрать ситуацию, когда при некотором изменении структуры первые 1000 XML-к будут валидны по старому валидатуру, а 1001 первый стал не валиден.
И как это ловить?
Иногда оно всплывает через месяц, иногда через год. У меня было через пару месяцев, под конец проекта(проект был на 3-4 месяца). Пришлось попотеть, чтобы успеть. Да и понервничать.
было. Возможно немного невнятно.
Вот оно
поясняю чуть по подробней:
Допустим у нас клиент, который читает данные с REST сервиса.
Допустим вы в парсере допустили ошибку. тег не так назвали. поставили лишнюю букву или пропустили. Или перепутали два тега в процессе разработки копипастом. Итог, данные в объекте либо пустые, либо не те.
Если пустые, то бывает иногда что-нибудь отвалится, а если не те — то это вообще сложно ловить. Я такие вещи ловил юнит тестами, если этого нет, то такой косяк можно поймать:
— внимательными глазами разработчика, который делает вам Code Review (или вы сами проверяли, увидели, так тоже бывает).
— внимательными глазами тестера, который будет сравнивать вход-выход
А может случиться так, что никогда не поймаете. Всплывает уже в процессе эксплуатации через какое-то время.
Я тоже так делал, только в Java. К тому же ответ тоже можно десериализовать в объект по тем же аннотациям. То есть этот фокус в обе стороны работает. К тому же, легко покрывается тестами.
Проблема в том, что эти объекты пришлось руками описывать. Использовать WADL не вышло, сторонний сервис его не предоставлял.
Расскажите подробней: что вы делали, какие инструменты
Проблема 1, это работает только для Javа клиентов. В динамических языках всё динамическое. Поэтому если сильно хочется, прокси придется делать самому.
Идеология SOAP уже говорит, что нужно проверять данные. Поэтому все клиенты SOAP как-то реализуют поддержку валидации, без нее же ничего работать не будет.
Проблема 2, чтобы генерить прокси для REST, нужно сначала иметь файл WADL для этого сервиса. Я пока ещё не видел ни одного популярного сервиса REST, который бы предоставлял WADL файл(скажите мне, если найдете такой, попробую погенирить для него прокси на java, интересно, будет ли вообще работать).
Скорее наоборот, часто разработчики совсем отходят в сторону от REST(когда по одному урлу доступно несколько разных типов объектов с одной шапкой и разными данными внутри).
если формат данных будет не такой, как WSDL, то обмен данными просто не будет работать. Это и называется, он сам найдет.
Для REST такое тоже есть WADL, но проблема в том, что многие разработчики считают, что он не укладывается в архитектуру REST и потому он не нужен.
А кому-то просто лень реализовывать генерацию ещё одной XML, которая только всё усложняет.
Буду, но не там, где вы думаете.
простите, похоже вы не так поняли то, что я имел в виду.
Я не за, и не против REST. Более того, в предпоследнем проекте делал обмен на REST, в последнем на SOAP. Поэтому у меня сложилось свое мнение относительно этих двух идей реализаций обмена данными.
Вариант первый. Вы пишите сервер, клиенты пишут все остальные. Главное, не вы. К тому же, клиентов туча и они разношерстные (разные языки, платформы и т.п.).
Тут я думаю лучше использовать REST. Плюс в том, что отдаются данные в каком-нибудь стандартном формате. Например, XML. Добавляем сюда весь богатый инструментарий по валидации этих данных — и всё в шоколаде. Главное вы отдаете данные правильно. Остальное вас не касается. Пример, Twitter и тому подобное.
Тут нареканий нет, очень удобная и гибкая архитектура.
SOAP же в этом случае применять не очень удобно, т.к. будет много накладных проблем с разными версиями SOAP а так же с особенностями реализации клиента SOAP на каждой из платформ.
Вариант второй, и клиент, и сервер ваши. Вам нужно передать объект А от сервера к клиенту или наоборот. В этом случае SOAP дает решение из коробки. Поднимаем сервер, описываем объект и у нас всё работает.
А теперь про ошибку, если я беру данные с какого-либо REST-сервиса, то по-хорошему нужно проверять, а правильно ли я их беру. Эту проверку осуществляет клиент, а не сервер.
Для REST вам придется писать её руками, или не писать, но при этом придется больше внимания уделить тестированию (никто не даст гарантии, что при очередном рефакторинге у вас чего-нибудь не отвалится).
С точки зрения теории можно любую задачу раскидать на объекты.
Объекты нужно создавать, задавать им параметры, получать их данные.
Далее объекты = ресурсы. и тогда к ним можно применять идеологию REST.
Получается достаточно красиво. А теперь пример задачи на вскидку.
Есть сервис, которого можно попросить удаленно что-нибудь сделать.
Пусть он всё делает в фоне.
схема общения такая, создаем задачу, запоминаем её ID.
Ждем, спрашиваем не готово ли. (можно и не ждать, а ожидать какого-либо события, переданного как-то, но не в этом суть, пусть для простоты будет так)
Получаем по ID результат.
Казалось бы, очень красиво всё ложится в REST.
Пишем ресурс задачи. Создание её, получение данных и т.п.
Дошли до клиента. выходит — нужно писать логику, сформировать XML(JSON), отослать, получить назад XML(JSON) обработать.
сформировать урл для получения данных для задачи. опять послать запрос, получить результат распарсить.
Если пишем на Java, то можно красиво смапить XML в объекты(хотя и). На других языках получается всё менее красиво, слишком много телодвижений.
Главный для меня минус, если структура сообщений поменяется (или мы в ней сделали ошибку), мы 100 лет будет искать ошибку. Как проверять скопировались данные или нет — тоже не понятно. Лучший способ, покрыть обильно данный код тестами. в итоге получается такая жирненькая задачка.
Пишем аналог на SOAP. Описываем сервис, он должен обмениваться объектами. Создаем задачу вызовом одного метода. получаем результат вызовом другого метода. Если результат получен — сразу у нас в программе объект с данными(если язык это поддерживает).
никаких XML, никакого парсинга. Нужно добиться чтобы версии SOAP совпадали и клиенты их правильно поддерживали.
Трудоемкость такой задачи на порядок меньше. Плюс контроль данных, которые приходят.
Итог, задача красиво ложится на REST архитектуру, а в SOAP её проще и быстрее реализовать по трудоемкости. Т.к. SOAP берет часть работы по валидации данных на себя. За счет этого оно и проще.
Проблему частично решает WADL. Но, генераторы кода клиента есть только на Java.
Итог для меня, простые вещи без какой-то особой логики можно реализовывать на REST.
Клиент пишется в 2 строчки, особой валидации не нужно и т.п.
Когда система усложняется, то нужно уже думать — как оно лучше, удобней и проще реализовать.
А менеджеры при этому думают, что работа при этом пойдет быстрее. как же…
Думаю, либо у человека дома не всё в порядке, либо работой перегружен, что просто срывается. Такого в отпуск срочно, пусть проспится, а потом решит свои домашние проблемы.
Первое. Конструктивный диалог иногда помогает. Мы же взрослые люди.
Второе. В каждом проекте есть соглашения разработки. Разработчик должен делать так, как принято в проекте, а не так, как ему хочется. Те или иные решения принимались не из-за хорошей жизни. А если они прижились, что значит они работают. А иначе всё будет — как в басне Крылова про 3-х животных. Если кто-то не следует соглашениям, то с этим тоже нужно что-то делать. Например, бить по рукам… :( но это уже крайний вариант
В ответ на:
Конструктивный диалог и предложение более качественных решений позволяют побороть это явление.
«управляющий» (если он адекватен) видит, что человек в теме, и дает подчиненному свободу решать задачу по его схеме.
Побывал в обоих ролях. Мне удавалось доказывать, свое мнение. И мне тоже доказывали мнение те, кем мне доводилось руководить. Так происходит потому, что человек решающий задачу на месте в самой задаче ориентируется лучше(если, конечно, он не начинающий, или просто новый человек в проекте, или ещё хуже — быдлокодер), чем руководитель.
А теперь позволю себе оставить свое мнение по поводу микроменеджмента:
я думаю, что он необходим только в одном случае — как одно из средств для обучения.
Я делал так:
сначала давал повозиться человеку в своем коде и документации 1-2 дня; пусть сам разберется;
если не разобрался, давал ссылки на документацию, литературу и на примеры — как нужно.
если и это не помогло, то корректировал решение сам, либо часть решения, объяснял как нужно и почему так, заставлял доделать — как нужно; возможно на это уходило несколько итераций
Далее следующая задача по той же схеме. После нескольких задач человек растет быстрее, и достаточно просто проглядывать его код на явные косяки.
Пару раз схема не срабатывала. В проекте было много новичков, не хватало времени работать с каждым. Да и объясняю я не очень понятно. В итоге, быдлокод был жутким… Но к концу проекта народ стал писать по лучше.
Итог, мы все учились понемногу...)
у нас тоже на работе есть настольный тенис.
одна-две партейки раз в 3 часа позволяет размяться и прочистить мозги.
А если в это время ещё и проветриваем помещение, то можно играть и двое на двое.