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

Ответ 1

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

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

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

Ответ 2

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

Ответ 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

Ответ 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.

Ответ 5

Всего несколько точек:

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

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

Ответ 6

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

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

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

Ответ 7

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

./Алекс

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