Можете ли вы помочь прояснить некоторые моменты, касающиеся услуг RESTful и генерации кода? - PullRequest
5 голосов
/ 03 марта 2011

Я изо всех сил пытался понять несколько моментов, которые я продолжаю читать о сервисах RESTful. Я надеюсь, что кто-то может помочь прояснить.

1a) Похоже, что при создании кода RESTful возникает общее отвращение к сгенерированному коду.

1b) Аргумент, что если вы используете WADL для генерации клиента для службы RESTful, то при изменении службы - ваш код клиента.

Почему я не понимаю: ссылаетесь ли вы на WADL и используете сгенерированный код, или вы вручную извлекли данные из ответа RESTful и отобразили их в свой пользовательский интерфейс (или что бы вы ни делали с ними), если что-то изменится в базовом сервисе похоже, что в обоих случаях код будет сломан. Например, если возвращаемые данные изменяются с FirstName и LastName на FullName, в обоих случаях вам придется обновить код, чтобы захватить новое поле и, возможно, обработать его по-разному.

2) Аргумент, что RESTful-сервисам не нужен WADL, потому что возвращаемые типы должны быть хорошо известными MIME-типами, и вы уже должны знать, как их обрабатывать.

Почему я не понимаю: ожидается ли, что для каждого «типа» данных, возвращаемых службой, будет существовать уникальный тип MIME? Если это так, означает ли это, что потребитель услуг RESTful должен прочитать RFC, чтобы определить структуру возвращаемых данных, как использовать каждое поле и т. Д .?

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

Ответы [ 2 ]

4 голосов
/ 13 марта 2011

ОТДЫХ может быть очень тонким.Я также много читал об этом, и время от времени я возвращался и читал главу 5 диссертации Филдинга , каждый раз находя больше понимания.В первый раз это было так же ясно, как грязь (хотя некоторые вещи имели смысл), но стало лучше, когда я попытался применить принципы и использовать строительные блоки.

Итак, исходя из моего текущего понимания, давайте попробуем:

Почему RESTafarians не любит генерацию кода?

Краткий ответ: ЕслиВы используете гипермедиа (+ ссылки) Нет необходимости .

Контекст: явное определение контракта (WADL) между клиентом и сервером не уменьшает сцепление достаточно : Если вы меняете сервер, клиент ломается, и вам необходимо восстановить код.(ИМХО даже автоматизация - это всего лишь патч к основной проблеме связывания).

REST помогает разделить на разных уровнях. Обнаружение гипермедиа - один из самых важных товаров для начала.См. Также связанную концепцию HATEOAS

Мы позволяем клиенту «выяснить», что можно сделать из ресурса, над которым мы работаем , вместо того, чтобы определять контракт раньше.Мы загружаем ресурс, проверяем «именованные ссылки» и затем следуем по этим ссылкам или заполняем формы (или ссылки на формы), чтобы обновить ресурс.Сервер действует как руководство для клиента с помощью опций, которые он предлагает в зависимости от состояния.(Подумайте, бизнес-процесс / рабочий процесс / поведение).Если мы используем договор, нам нужно знать эту «внешнюю» информацию и обновлять договор об изменениях.

Если мы используем гипермедиа со ссылками, нет необходимости иметь «отдельный договор».Все включено в гипермедиа - зачем разрабатывать отдельный документ?Даже шаблоны URI не содержат никакой информации, но, если хранить их просто, они могут работать как Amazon S3.

Да, нам по-прежнему нужно общее основание для поддержки при передаче представлений (гипермедиа), поэтому мы определяем ваши собственные типы мультимедиа илииспользуйте общепринятые, такие как Atom или Микроформаты .Таким образом, с ограничениями основных строительных блоков (ссылка + формы + данные - гипермедиа) мы уменьшаем связь, сводя к минимуму внеполосную информацию.

Сначала кажется, что использование гипермедиа не меняет воздействияизменений :): Но есть тонкие различия.Во-первых, если у меня есть WADL, мне нужно обновить другой документ и развернуть / распространить.Использование чистой гипермедиа не оказывает никакого влияния, поскольку оно встроено.(Представьте, что изменения происходят через сложное переплетение систем).В соответствии с вашим примером наличие FirstName + LastName и добавление FullName на самом деле не влияет на клиентов, но удаление First + Last и замена на FullName влияет даже на гипермедиа.

Примечание: унифицированный интерфейс REST (ограничения глагола)- GET, PUT, POST, DELETE + другие глаголы) отделяет реализацию от сервисов.

Возможно, я совершенно не прав, но другой возможностью может быть «психологический откат» к генерации кода: WADL заставляет задуматься оWSDL (контрактная) часть в «традиционных веб-сервисах (WSDL + SOAP)» / RPC, которая идет вразрез с REST.В состоянии REST передается через гипермедиа, а не через RPC, которые являются вызовами методов для обновления состояния на сервере.

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

0 голосов
/ 10 марта 2011

Я довольно долго работал над проектами API. Чтобы ответить на ваш первый вопрос.

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

Вы должны понимать, что WADL - это Соглашение . Если это должно измениться, то клиент должен быть уведомлен. Чтобы избежать взлома клиентского кода, мы выпускаем новую версию API.

Версия 1.0 будет иметь имя и фамилию, не нарушая ваш код. Мы выпустим версию 1.1, которая изменится на Полное имя.

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

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

WADL предназначен для генерации кода и служит контрактом. При этом вы можете использовать JAXB или любую среду отображения для преобразования строки JSON в сгенерированные объекты bean.

Если не WADL, вам не нужно проверять каждый элемент, чтобы определить тип. Вы можете легко сделать это.

var obj = jQuery.parseJSON ( '{ "имя": "Джон"}); alert (obj.name === "Джон");

Дайте мне знать, если у вас есть какие-либо вопросы.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...