Как правильно сделать ОТДЫХ?

36

В настоящее время все делают SOA , даже если некоторые на самом деле не понимают, что это такое. Поэтому они делают это неправильно. Используя это в качестве аналогии, я знаю, что такое REST (или, по крайней мере, я так думаю), и хочу сделать кое-что из этого. Но я хочу сделать это правильно.

Итак, мой вопрос, как правильно сделать REST?

JohnDoDo
источник
1
Stack Overflow тег «rest» вики, похоже, настолько близок к каноническому ресурсу в контексте сети Stack Exchange
gnat
17
Я просто закрыл глаза на некоторое время ... может быть, покататься на велосипеде, а затем лечь.
Эдвард Стрендж
Разве REST просто не использует URL-адрес, такой как mydomain.com/accounts и HTTP-глагол, для вызова операции? Где глагол указывает, хотите ли вы получить, создать, обновить или удалить данные? Когда я думаю, что REST - это то, о чем я думаю.
Маффин Человек
2
@ Ник, это самая распространенная интерпретация, «настоящую вещь» гораздо сложнее выманить, и (насколько я могу судить) гораздо сложнее найти ее реально реализованную где угодно ... (см. Ответ Уилка)
Бенджол
3
@ Ник, ты понимаешь, это не REST, а RPC через HTTP .

Ответы:

30

Ну, есть много способов узнать, как создать веб-приложение RESTful, и нет, единственного правильного способа не существует. RESTful не является стандартом, но использует набор стандартов (HTTP, URI, Mime Type, ...).

Начните с этого: Как я объяснил REST моей жене

Затем перейдите к следующему: RESTful Web Services Cookbook

А затем приложите все усилия для разработки веб-приложений, потому что лучший способ учиться - это проводить эксперименты, и вы можете многому научиться на своих ошибках;)

Не беспокойтесь, если ваши первые веб-приложения не будут полностью RESTful: вы найдете способ сделать это!

Итак, цитируя Оби-Вана Кеноби, «да пребудет с тобой сила!» ;)

РЕДАКТИРОВАТЬ

Хорошо, позвольте мне быть более конкретным. Вы хотите сделать RESTful веб-приложение, а? Ну, как я уже сказал, есть много способов сделать это, но это главное руководство.

Определение

REST (Transfer State Transfer) - это стиль архитектуры программного обеспечения для распределенной системы (например, WWW). Это не стандарт, но он использует набор стандартов: HTTP, AJAX, HTML, URI, Mime Type и т. Д. Мы говорим о представлении ресурса, а не о самом ресурсе. Взято из «Как я объяснил REST моей жене»:

Жена : веб-страница является ресурсом?

Райан : Вид. Веб-страница является представлением ресурса. Ресурсы - это просто понятия.

Архитектурные ограничения

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

Единый интерфейс

  • Идентификация ресурсов : каждый ресурс должен быть идентифицирован по URI.
  • Протокол : чтобы получить доступ к клиенту и серверу связи, протокол должен быть сделан раньше. Каждый запрос может иметь правильный MIME-тип (application / xml, text / html, application / rdf + xml и т. Д.), Правильные заголовки и правильный HTTP-метод (см. Описание CRUD ниже).

CRUD

Итак, мы увидели, что для идентификации ресурсов мы можем использовать URI, но нам нужно что-то еще для действий (добавить, изменить, удалить и т. Д.): Отличный прием в CRUD (создание, чтение, обновление и удаление).

  • Создать { HTTP: POST } { SQL: INSERT } => создать новый ресурс
  • Читать { HTTP: GET } { SQL: SELECT } => получить ресурс
  • Обновить { HTTP: PUT } { SQL: UPDATE } => изменить ресурс
  • Delete { HTTP: DELETE } { SQL: DELETE } => удалить ресурс

Теперь, что касается PUT и DELETE, могут возникнуть некоторые технические проблемы (вы получите их с помощью HTML-формы): часто разработчики обходят эту проблему, используя POST для каждого запроса «PUT» и «DELETE». Официально вы должны использовать PUT и DELETE. Кстати, делай что хочешь. Мой опыт подталкивает меня к использованию POST и GET каждый раз.

--- Следующая часть должна быть использована, но это не связь REST: это касается связанных данных ---

URI

Абстрактный URI из технических деталей! Попрощайтесь с URI следующим образом:

http://www.example.com/index.php?query=search&id=9823&date=08272012

Перепроектируйте URI! Возьмите ссылку выше и измените ее следующим образом:

http://www.example.com/search/2012/08/27/9823

Это намного лучше, а? Это может быть сделано:

Другое дело: используйте разные URI для представления разных ресурсов:

Обратите внимание : about.html и about.rdf не являются файлами! Они могут быть результатом преобразования XSLT!

Согласование контента

Если вы достигли этой точки, поздравляю! Возможно, вы готовы получить более абстрактные понятия, потому что мы входим в технические детали семантической паутины;) Ну, когда ваш клиент хочет ресурс, он обычно делает следующий запрос:

GET http://www.example.com/about
Accept: application/rdf+xml

Но сервер не будет отвечать about.rdf, потому что у него другой URI ( http://www.example.com/about.rdf ). Итак, давайте посмотрим на шаблон 303 ! Сервер вернет это:

303 See Other
Location: http://www.example.com/about.rdf

И клиент перейдет по ссылке, возвращенной следующим образом:

GET http://www.example.com/about.rdf
Accept: application/rdf+xml

Наконец, сервер вернет запрошенный ресурс:

200 OK
about.rdf

Не волнуйтесь: ваше клиентское приложение ничего с этим не сделает! Шаблон 303 должен быть сделан серверным приложением, а ваш браузер сделает все остальное;)

Вывод

Часто теория далека от практики. Да, теперь вы знаете, как спроектировать и разработать приложение RESTful, но приведенные выше рекомендации являются лишь подсказкой. Вы найдете свой лучший способ создания веб-приложений, и, вероятно, он не будет таким, как того требует теория. Не наплевать: D!

Список используемой литературы

Веб-сервисы RESTful, Самер Тяги

REST API должны быть управляемы гипертекстом, Рой Томас Филдинг

Веб-сервисы RESTful: основы, Алекс Родригес

Webber REST Workflow

Wilk
источник
1
Вы можете подумать о добавлении этой ссылки , которая является наиболее полным руководством, которое я встречал.
Бенджол
Я видел, как PUT и POST использовались с заменой значений (в зависимости от вашего ответа): POST -> create, PUT -> update. Любая идея, какое значение более широко используется?
Андрес Ф.
@Andres F .: jcalcote.wordpress.com/2008/10/16/… говорит: Create = PUT, если вы отправляете полный контент указанного ресурса (URL). Create = POST, если вы отправляете команду на сервер для создания подчиненного указанного ресурса, используя некоторый алгоритм на стороне сервера. Update = PUT, если вы обновляете полное содержимое указанного ресурса. Update = POST, если вы запрашиваете у сервера обновление одного или нескольких подчиненных указанного ресурса.
Уилк
@Benjol: я собираюсь редактировать с вашим предложением;) Спасибо!
Уилк
1
@Wilk Некоторые вещи нужно учитывать! Вероятно, почему никто не понимает это правильно: P
Андрес Ф.
5

ОТДЫХ Библейская книга или что-то ....

Библейская книга не нужна; У меня были точно такие же вопросы, и я узнал все, что мне нужно или что я хотел знать о REST, прочитав эти три статьи:

  1. Введение в HTTP и REST для начинающих от Net Tuts +
  2. Web-сервисы RESTful: основы от IBM developerWorks
  3. RESTful HTTP на практике из InfoQ

Но я хочу сделать это правильно.

Как вы прочтете в статьях выше, ключевым моментом является представление о доступных частях вашего приложения как о «ресурсах», которые можно создавать, извлекать, обновлять или удалять с использованием существующих «глаголов» HTTP: GET, PUT, POST , УДАЛЯТЬ.

Кроме того, знайте разницу между PUT и POST и когда их использовать. GET, PUT, и DELETE должны быть идемпотентными транзакциями, POST не должен.

Кроме того, правильно используйте коды состояния HTTP при обратной связи с клиентом.

CFL_Jeff
источник