REST и веб-сервисы - не понимая их

Хорошо, название более или менее говорит обо всем. Я понимаю, что такое REST - использование существующих HTTP-процедур (POST, GET и т.д.) Для облегчения создания/использования веб-сервисов. Я более смущен тем, что определяет, что такое веб-сервис, и как REST фактически используется для создания/публикации службы.

Например, Twitter, из того, что я прочитал, является RESTful. Что это значит? Как вызывается HTTP-процедуры? Когда я пишу твит, как задействуется REST и как он отличается от простого использования серверного языка и хранения этих текстовых данных в базе данных или файле?

Ответ 1

Эта концепция также немного расплывчата для меня, но, посмотрев на ваш вопрос, я решил уточнить ее немного больше для себя.

обратитесь к этой ссылке в msdn и this.

В основном, похоже, что это использование методов http (Get/Post/Delete) для определения воздействия ресурсов, которое позволяет приложение. Например: Скажем, у вас есть URL-адрес:

http://Mysite.com/Videos/21

где 21 - идентификатор видео. Мы также можем определить, какие методы разрешены для этого url - GET для извлечения ресурса, POST для обновления/создания, удаления для удаления.

Как правило, это выглядит как организованный и чистый способ разоблачения ваших ресурсов приложений и операций, которые поддерживаются на них с помощью методов http

Ответ 2

Архитектура RESTful предоставляет уникальный URL-адрес, который определяет каждый ресурс индивидуально и передает через HTTP-команды действия соответствующие действия для одного и того же URL-адреса.

Лучший способ, я могу думать, чтобы объяснить это, - думать о каждой модели данных в вашем приложении как о уникальном ресурсе, а REST помогает маршрутизировать запросы без использования строки запроса в конце URL-адреса, например, вместо /posts/&q=1, вы просто используете posts/1.

Это проще понять на примере. Это будет REST-архитектура, обеспечиваемая Rails, но дает вам хорошее представление об этом контексте.

GET /tweets/1 ⇒ означает, что вы хотите получить твит с идентификатором 1
GET /tweets/1/edit ⇒ означает, что вы хотите перейти к редактированию действия, связанному с твитом с идентификатором 1
PUT /tweets/1 ⇒ PUT говорит, чтобы обновить этот твит, а не извлечь его
POST /tweets ⇒ POST говорит, что у меня есть новый, добавьте его в db, я не могу дать id cuz, у меня его нет, пока я не сохраню его в db
DELETE /tweets/1 ⇒ удалить его из базы данных

Ресурсы часто вложены, хотя в twitter это может быть как

GET /users/1/jedschneider/1 ⇒ у пользователей много твитов; получить пользователя с идентификатором jedschneider и его твитом id 1

Архитектура для реализации REST будет уникальной для приложения, а некоторые приложения поддерживают по умолчанию (например, Rails).

Ответ 3

Вы можете начать с эту отличную вводную запись. Он охватывает все это от начала до конца.

Ответ 4

Вы боретесь, потому что есть два относительно разных понимания термина "REST". Я попытался ответить на это ранее, но достаточно сказать: API Twitter не является RESTful в строгом смысле слова, и ни один из них не является Facebook.

sTodorov ответ показывает общий недоразумение, в котором говорится о использовании все четыре HTTP-глагола и присвоение различных URI ресурсам (обычно с документацией по всем URI). Поэтому, когда Twitter вызывает REST, они просто делают именно это, наряду с большинством других API RESTful.

Но этот так называемый REST не отличается от RPC, за исключением того, что RPC (с IDL или WSDL) может вводить средства генерации кода за счет более высокой связи.

REST фактически не RPC. Это архитектура для распределенных систем на основе гипермедиа, которая может не соответствовать счету для всех, кто делает API. В связанной статье MSDN гипермедиа срабатывает, когда они говорят о <Bookmarks>http://contoso.com/bookmarkservice/skonnard</Bookmarks>, раздел заканчивается этим предложением:

Эти представления делают возможным перемещение между различными типами ресурсов

который является основным принципом, который нарушает большинство API RESTful. В статье не указано, как документировать RESTful API, и если бы это было так, было бы намного понятнее, что клиентам придется перемещаться по ссылкам, чтобы делать что-то (RESTful), и не может быть предоставлено множество шаблонов URI (RPCish).