REST и веб-сервисы - имеющий проблему, понимая их
Ну, в заголовке более или менее говорится все это. Я сортирую, понимают то, что REST - использование существующих процедур HTTP (POST, ДОБЕРИТЕСЬ, и т.д.) упрощать создание/использование веб-сервисов. Я более смущен на том, что определяет то, что веб-сервис и как REST на самом деле используется для делания/выставления сервиса.
Например, Твиттер, от того, что я считал, является УСПОКОИТЕЛЬНЫМ. Что это на самом деле означает? Как процедуры HTTP вызываются? Когда я пишу твит, как REST включен, и как он несколько отличается, чем простое использование серверного языка и хранить те текстовые данные в базе данных или файле?
4 ответа
Эта концепция также немного туманна для меня, но после изучения вашего вопроса я решил прояснить ее для себя.
Пожалуйста, обратитесь к этой ссылке в msdn и этой.
В основном, кажется, что речь идет об использовании http-методов (Get/Post/Delete) для определения разрешенных приложением ресурсов. Например: Допустим, у вас есть URL :
http://Mysite.com/Videos/21
где 21 - идентификатор видео. Далее мы можем определить, какие методы разрешены для этого URL - GET для получения ресурса, POST для обновления/создания, Delete для удаления.
В целом, это кажется организованным и чистым способом раскрытия ресурсов вашего приложения и операций, которые поддерживаются для них с использованием http-методов
Вы можете начать с этой превосходной вводной статьи . Он охватывает все от начала до конца.
Архитектура RESTful предоставляет уникальный URL-адрес, который определяет каждый ресурс индивидуально и с помощью глаголов действия HTTP выводит соответствующее действие, которое необходимо выполнить для одного и того же URL-адреса.
Лучший способ объяснить это - рассматривать каждую модель данных в вашем приложении как уникальный ресурс, а REST помогает маршрутизировать запросы без использования строки запроса в конце URL-адреса, например, вместо / posts / & q = 1 , вы должны просто использовать posts / 1 .
Это легче понять на примере. Это будет архитектура REST, которую обеспечивает Rails, но она дает вам хорошее представление о контексте.
GET / tweets / 1⇒ означает, что вы хотите получить твит с идентификатором1GET / tweets / 1 / edit⇒ означает, что вы хотите перейти к действию отредактируйте, связанный с твитом с идентификатором1PUT / tweets / 1⇒ PUT говорит, что обновлять этот твит, а не получать егоPOST / tweets⇒ POST говорит, что я получил новый, добавьте его в базу данных, я не могу указать идентификатор, потому что у меня его еще нет, пока я не сохраню его в базе данныхDELETE / tweets / 1⇒ удалить его из базы данных
Ресурсы часто вложенные, поэтому в твиттере это может быть вроде
GET / users / 1 / jedschneider / 1⇒ у пользователей много твитов; получить пользователя с идентификаторомjedschneiderи идентификатором твита1
Архитектура для реализации REST будет уникальной для приложения, при этом некоторые приложения будут поддерживаться по умолчанию (например, Rails).
Вы боретесь, потому что есть два относительно разных понимания термина «ОТДЫХ». Я пытался ответить на этот вопрос ранее , но достаточно сказать: API Twitter не является RESTful в строгом смысле слова, как и Facebook.
Ответ Стодорова показывает распространенное недоразумение , что речь идет о использовании всех четырех HTTP-глаголов и назначении разных URI ресурсам (обычно с документацией, что все URI) . Поэтому, когда Twitter вызывает REST, они просто делают это вместе с большинством других RESTful API.
Но этот так называемый REST ничем не отличается от RPC , за исключением того, что RPC (с IDL или WSDL) может вводить средства генерации кода за счет более высокой связи.
REST - это , на самом деле не RPC. Это архитектура для распределенных систем на основе гипермедиа, которая может не соответствовать всем требованиям, предъявляемым к API. В связанной статье MSDN гипермедиа включается, когда говорят о , раздел заканчивается этим предложение:
Эти представления позволяют перемещаться между разными типами ресурсов
, что является основным принципом, нарушаемым большинством RESTful API.В статье не говорится, как задокументировать RESTful API , и если бы это было сделано, было бы намного яснее, что клиентам пришлось бы переходить по ссылкам, чтобы делать что-то (RESTful), и не были бы предоставлены с множеством шаблонов URI (RPCish).