Можете ли вы объяснить веб-концепцию RESTful?

Question

В поисках четких и кратких объяснений этой концепции.

Answer 1

RESTful-приложение - это приложение, которое предоставляет свое состояние и функциональность в виде набора ресурсов, которыми клиенты могут манипулировать, и соответствует определенному набору принципов:

• Все ресурсы являются уникально адресуемыми, обычно через URI; однако можно использовать и другую адресацию.
• Все ресурсы можно манипулировать с помощью ограниченного набора известных действий, обычно CRUD (создание, чтение, обновление, удаление), которые чаще всего представлены через HTTP POST, GET, PUT и DELETE; это может быть другой набор или подмножество - например, некоторые реализации ограничивают набор только для чтения и изменения (GET и PUT), например
• Данные для всех ресурсов передаются через любое из ограниченного числа известных представлений, обычно HTML, XML или JSON;
• Связь между клиентом и приложением осуществляется по протоколу без сохранения состояния, который позволяет использовать многоуровневые посредники, которые могут перенаправлять и прозрачно кэшировать пакеты запросов и ответов для клиента и приложения.

Статья Википедии , указанная Тимом Скоттом, дает более подробную информацию о происхождении REST, подробные принципы, примеры и т. Д.

Answer 2

Лучшее объяснение, которое я нашел, находится в этом учебнике REST .

Answer 3

REST в качестве примера:

POST /user
fname=John&lname=Doe&age=25

Сервер отвечает:

200 OK
Location: /user/123

В дальнейшем вы можете получить информацию о пользователе:

GET /user/123

Сервер отвечает:

200 OK
<fname>John</fname><lname>Doe</lname><age>25</age>

Для обновления:

PUT /user/123
fname=Johnny

Answer 4

Честно говоря, ответ зависит от контекста. REST и RESTful имеют значения в зависимости от того, какой язык или среду вы используете или чего вы пытаетесь достичь. Поскольку вы отметили свой вопрос в разделе «веб-сервисы», я отвечу в контексте веб-сервисов RESTful, которые по-прежнему относятся к широкой категории.

Веб-службы RESTful могут означать что угодно, от строгой интерпретации REST, где все действия выполняются строго "RESTful", до протокола, который представляет собой простой XML, то есть не SOAP или XMLRPC. В последнем случае это является неправильным: такой протокол REST на самом деле является «простым старым XML» (или «POX») протоколом . Хотя протоколы REST обычно используют XML и, как таковые, являются протоколами POX, это не обязательно должно иметь место, и обратное неверно (просто потому, что протокол, использующий XML, не делает его RESTful).

Без лишних слов настоящий RESTful API состоит из действий, выполняемых над объектами, которые представлены используемым методом HTTP и URL-адресом этого объекта. Действия касаются данных, а не того, что делает метод. Например, действия CRUD (создание, чтение, обновление и удаление) могут сопоставляться с определенным набором URL-адресов и действий. Допустим, вы взаимодействуете с API фотографий.

• Чтобы создать фотографию, вы должны отправить данные с помощью запроса POST в / photos. Это позволит вам узнать, где находится фотография через заголовок Location, например / фотографии / 12345
• Для просмотра фотографии вы должны использовать GET / photos / 12345
• Чтобы обновить фотографию, вы должны отправить данные с помощью запроса PUT на /photos/12345.
• Чтобы удалить фотографию, вы должны использовать DELETE / photos / 12345
• Чтобы получить список фотографий, вы должны использовать GET /photos.

Могут быть реализованы другие действия, например, возможность копировать фотографии с помощью запроса COPY.

Таким образом, метод HTTP, который вы используете, сопоставляется непосредственно с целью вашего вызова, а не отправляет действие, которое вы хотите выполнить, как часть API. Для сравнения, API без RESTful может использовать гораздо больше URL и использовать только действия GET и POST. Итак, в этом примере вы можете увидеть:

• Чтобы создать фотографию, отправьте POST в / photos / create
• Для просмотра фотографии отправьте GET в / photos / view / 12345
• Чтобы обновить фотографию, отправьте POST в / photos / update / 12345
• Чтобы удалить фотографию, отправьте GET в / photos / delete / 12345
• Чтобы получить список фотографий, отправьте GET в / photos / list

Вы заметите, как в этом случае URL-адреса различаются, а методы выбираются только из технической необходимости: для отправки данных вы должны использовать POST, в то время как все другие запросы используют GET.

Answer 5

Всего несколько баллов:

• RESTFul не зависит от используемой вами платформы. Это зависит от архитектурного стиля, который он описывает. Если вы не соблюдаете ограничения, вы не RESTful. Ограничения определены на половине страницы главы 5 документа Роя Филдинга, я призываю вас пойти и прочитать его.
• Идентификатор является непрозрачным, и не передает какую-либо информацию за пределы идентификации ресурса. Это NMAE, а не входные данные, просто имена. что касается клиента, он не имеет никакой логики или значения, кроме знания того, как создавать строки запросов из тега формы. Если ваш клиент строит свои собственные URI с использованием схемы, которую вы определили заранее, вы не успокаиваетесь.
• Использование или не использование всех глаголов http на самом деле не является ограничением, и вполне приемлемо проектировать архитектуру, которая поддерживает только POST.
• Кэширование, высокая развязка, отсутствие состояния сеанса и многоуровневая архитектура - это те моменты, о которых мало кто говорит, но они наиболее важны для успеха архитектуры RESTful.

Если вы не тратите большую часть своего времени на разработку формата документа, вы, вероятно, не занимаетесь REST.

Answer 6

Это означает использование имен для идентификации команд и параметров.

Вместо имен, являющихся просто дескрипторами или именами, само имя содержит информацию. В частности, информация о том, что запрашивается, параметры для запроса и т.д ..

Имена - это не "корни", а действия и входные данные.

Answer 7

Я больше всего узнал, прочитав статьи, опубликованные на InfoQ.com: http://www.infoq.com/rest и книга веб-служб RESTful (http://oreilly.com/catalog/9780596529260/).

. / Alex

Отказ от ответственности: Я связан с InfoQ.com, но эта рекомендация основана на моем собственном опыте обучения.