Что такое RESTful-программирование?
Что такое RESTful-программирование?
37 ответов
Архитектурный стиль, называемый REST (представление состояния передачи), предусматривает, что веб-приложения должны использовать HTTP, как это первоначально предполагалось. Поиски должны использовать GET Запросы. PUT , POST , а также DELETE запросы должны использоваться для мутации, создания и удаления соответственно.
Сторонники REST предпочитают URL-адреса, такие как
http://myserver.com/catalog/item/1729
но архитектура REST не требует этих "красивых URL". GET-запрос с параметром
http://myserver.com/catalog?item=1729
каждый бит как RESTful.
Имейте в виду, что запросы GET никогда не должны использоваться для обновления информации. Например, запрос GET для добавления товара в корзину
http://myserver.com/addToCart?cart=314159&item=1729
не будет уместным. GET-запросы должны быть идемпотентными. То есть выдача запроса дважды не должна отличаться от его выдачи один раз. Вот что делает запросы кешируемыми. Запрос "добавить в корзину" не является идемпотентом - при его повторном добавлении в корзину добавляется две копии элемента. Запрос POST явно уместен в этом контексте. Таким образом, даже веб-приложению RESTful нужна доля запросов POST.
Это взято из превосходной книги Core JavaServer Faces книги Дэвида М. Гири.
REST - это основной архитектурный принцип сети. Удивительным моментом в Интернете является тот факт, что клиенты (браузеры) и серверы могут взаимодействовать сложным образом, и клиент ничего не знает заранее о сервере и размещаемых на нем ресурсах. Ключевым ограничением является то, что сервер и клиент должны согласовать используемое мультимедиа, которое в случае с Интернетом является HTML.
API, который придерживается принципов REST, не требует от клиента ничего знать о структуре API. Скорее, сервер должен предоставить любую информацию, необходимую клиенту для взаимодействия со службой. HTML-форма является примером этого: сервер указывает местоположение ресурса и обязательные поля. Браузер не знает заранее, куда отправить информацию, и он не знает заранее, какую информацию отправлять. Обе формы информации полностью предоставляются сервером. (Этот принцип называется HATEOAS: гипермедиа как двигатель состояния приложения.)
Итак, как это относится к HTTP, и как это может быть реализовано на практике? HTTP ориентирован на глаголы и ресурсы. Два глагола в обычном использовании - это GET и POST, которые, я думаю, все узнают. Однако стандарт HTTP определяет несколько других, таких как PUT и DELETE. Эти глаголы затем применяются к ресурсам в соответствии с инструкциями, предоставленными сервером.
Например, давайте представим, что у нас есть пользовательская база данных, которая управляется веб-службой. Наш сервис использует пользовательские гипермедиа на основе JSON, для которых мы назначаем mimetype application / json + userdb (может также существовать application/xml+userdb и application/what + userdb - могут поддерживаться многие типы мультимедиа). Клиент и сервер были запрограммированы для понимания этого формата, но они ничего не знают друг о друге. Как отмечает Рой Филдинг:
API-интерфейс REST должен потратить почти все свои описательные усилия на определение типов носителей, используемых для представления ресурсов и управления состоянием приложения, или на определение имен расширенных отношений и / или разметки с поддержкой гипертекста для существующих стандартных типов носителей.
Запрос на базовый ресурс / может вернуть что-то вроде этого:
Запрос
GET /
Accept: application/json+userdb
отклик
200 OK
Content-Type: application/json+userdb
{
"version": "1.0",
"links": [
{
"href": "/user",
"rel": "list",
"method": "GET"
},
{
"href": "/user",
"rel": "create",
"method": "POST"
}
]
}
Из описания наших СМИ мы знаем, что мы можем найти информацию о связанных ресурсах в разделах, называемых "ссылками". Это называется гипермедиа управления. В этом случае мы можем сказать из такого раздела, что мы можем найти список пользователей, сделав еще один запрос на /user:
Запрос
GET /user
Accept: application/json+userdb
отклик
200 OK
Content-Type: application/json+userdb
{
"users": [
{
"id": 1,
"name": "Emil",
"country: "Sweden",
"links": [
{
"href": "/user/1",
"rel": "self",
"method": "GET"
},
{
"href": "/user/1",
"rel": "edit",
"method": "PUT"
},
{
"href": "/user/1",
"rel": "delete",
"method": "DELETE"
}
]
},
{
"id": 2,
"name": "Adam",
"country: "Scotland",
"links": [
{
"href": "/user/2",
"rel": "self",
"method": "GET"
},
{
"href": "/user/2",
"rel": "edit",
"method": "PUT"
},
{
"href": "/user/2",
"rel": "delete",
"method": "DELETE"
}
]
}
],
"links": [
{
"href": "/user",
"rel": "create",
"method": "POST"
}
]
}
Мы можем многое сказать из этого ответа. Например, теперь мы знаем, что можем создать нового пользователя, разместив /user:
Запрос
POST /user
Accept: application/json+userdb
Content-Type: application/json+userdb
{
"name": "Karl",
"country": "Austria"
}
отклик
201 Created
Content-Type: application/json+userdb
{
"user": {
"id": 3,
"name": "Karl",
"country": "Austria",
"links": [
{
"href": "/user/3",
"rel": "self",
"method": "GET"
},
{
"href": "/user/3",
"rel": "edit",
"method": "PUT"
},
{
"href": "/user/3",
"rel": "delete",
"method": "DELETE"
}
]
},
"links": {
"href": "/user",
"rel": "list",
"method": "GET"
}
}
Мы также знаем, что можем изменить существующие данные:
Запрос
PUT /user/1
Accept: application/json+userdb
Content-Type: application/json+userdb
{
"name": "Emil",
"country": "Bhutan"
}
отклик
200 OK
Content-Type: application/json+userdb
{
"user": {
"id": 1,
"name": "Emil",
"country": "Bhutan",
"links": [
{
"href": "/user/1",
"rel": "self",
"method": "GET"
},
{
"href": "/user/1",
"rel": "edit",
"method": "PUT"
},
{
"href": "/user/1",
"rel": "delete",
"method": "DELETE"
}
]
},
"links": {
"href": "/user",
"rel": "list",
"method": "GET"
}
}
Обратите внимание, что мы используем различные HTTP-глаголы (GET, PUT, POST, DELETE и т. Д.) Для манипулирования этими ресурсами, и что единственное знание, которое мы предполагаем в части клиента, - это наше определение медиа.
Дальнейшее чтение:
- Гораздо лучшие ответы на этой странице.
-
Как я объяснил REST моей жене. - Как я объяснил REST моей жене.
- Мысли Мартина Фаулера
- API Paypal имеет средства управления гипермедиа
(Этот ответ был предметом большого количества критики за то, что упустил из виду. По большей части это была справедливая критика. То, что я первоначально описал, более соответствовало тому, как REST обычно применялся несколько лет назад, когда я сначала написал это, а не его истинное значение. Я пересмотрел ответ, чтобы лучше представить реальное значение.)
RESTful программирование о:
- ресурсы, идентифицируемые постоянным идентификатором: URIs - повсеместный выбор идентификатора в наши дни
- ресурсы, которыми манипулируют, используя общий набор глаголов: HTTP-методы - наиболее распространенный случай - почтенный
Create,Retrieve,Update,DeleteстановитсяPOST,GET,PUT, а такжеDELETE, Но REST не ограничивается HTTP, это просто наиболее часто используемый транспорт на данный момент. - фактическое представление, полученное для ресурса, зависит от запроса, а не от идентификатора: используйте заголовки Accept, чтобы контролировать, хотите ли вы XML, HTTP или даже объект Java, представляющий ресурс
- поддержание состояния в объекте и представление состояния в представлении
- представление отношений между ресурсами в представлении ресурса: связи между объектами встроены непосредственно в представление
- Представления ресурсов описывают, как можно использовать представление и при каких обстоятельствах его следует отбрасывать / повторно получать согласованным образом: использование заголовков HTTP Cache-Control
Последний, вероятно, является наиболее важным с точки зрения последствий и общей эффективности REST. В целом, большинство обсуждений RESTful, похоже, сосредоточены на HTTP и его использовании из браузера, а что нет. Я понимаю, что Р. Филдинг придумал термин, когда он описал архитектуру и решения, которые приводят к HTTP. Его тезис больше посвящен архитектуре и способности кеширования ресурсов, чем HTTP.
Если вас действительно интересует, что такое архитектура RESTful и почему она работает, прочитайте его тезис несколько раз и прочитайте все это, а не только главу 5! Далее рассмотрим, почему работает DNS. Прочитайте об иерархической организации DNS и о том, как работают рефералы. Затем прочитайте и рассмотрите, как работает DNS-кэширование. Наконец, прочитайте спецификации HTTP (в частности RFC2616 и RFC3040) и подумайте, как и почему кэширование работает так, как оно работает. В конце концов, он просто щелкнет. Последнее откровение для меня было, когда я увидел сходство между DNS и HTTP. После этого начинается понимание того, почему интерфейсы SOA и Message Passing масштабируемы.
Я думаю, что наиболее важная уловка для понимания важности архитектуры и влияний на производительность архитектур RESTful и Shared Nothing заключается в том, чтобы не зацикливаться на деталях технологии и реализации. Сконцентрируйтесь на том, кому принадлежат ресурсы, кто отвечает за их создание / обслуживание и т. Д. Затем подумайте о представлениях, протоколах и технологиях.
Вот как это может выглядеть.
Создайте пользователя с тремя свойствами:
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>
Чтобы изменить запись (lname а также age останется без изменений)
PATCH /user/123
fname=Johnny
Чтобы обновить запись (и, следовательно, lname а также age будет NULL):
PUT /user/123
fname=Johnny
Отличная книга о ОТДЫХЕ - ОТДЫХ на практике.
Должны быть чтения Передача состояния представления (REST), а API REST должны управляться гипертекстом
См. Статью Мартина Фаулерса " Модель зрелости Ричардсона" (RMM) для объяснения того, что такое сервис RESTful.
Чтобы быть RESTful, Служба должна выполнять Гипермедиа как Механизм Состояния Приложения. (HATEOAS), то есть он должен достичь уровня 3 в RMM, читайте статью для подробностей или слайды из выступления qcon.
Ограничение HATEOAS является аббревиатурой от Hypermedia как движка состояния приложения. Этот принцип является ключевым отличием между REST и большинством других форм клиент-серверной системы.
...
Клиент RESTful-приложения должен знать только один фиксированный URL-адрес для доступа к нему. Все будущие действия должны обнаруживаться динамически из гиперссылок, включенных в представления ресурсов, которые возвращаются с этого URL. Ожидается, что стандартизированные типы носителей также будут понятны любому клиенту, который может использовать RESTful API. (Из Википедии, свободной энциклопедии)
REST Litmus Test для веб-фреймворков - это аналогичный тест на зрелость для веб-фреймворков.
Подходя к чистому REST: научиться любить HATEOAS - это хороший набор ссылок.
REST и SOAP для публичного облака обсуждают текущие уровни использования REST.
REST и управление версиями обсуждают расширяемость, управление версиями, эволюционируемость и т. Д. Через модифицируемость
Что такое ОТДЫХ?
REST расшифровывается как представительский государственный трансферт. (Иногда его называют "ReST".) Он основывается на протоколе обмена данными с клиентом и сервером, не зависящем от состояния, и практически во всех случаях используется протокол HTTP.
REST - это стиль архитектуры для проектирования сетевых приложений. Идея состоит в том, что вместо использования сложных механизмов, таких как CORBA, RPC или SOAP, для соединения между машинами, простой HTTP используется для выполнения вызовов между машинами.
Во многих отношениях сама Всемирная паутина, основанная на HTTP, может рассматриваться как архитектура на основе REST. Приложения RESTful используют HTTP-запросы для публикации данных (создания и / или обновления), чтения данных (например, создания запросов) и удаления данных. Таким образом, REST использует HTTP для всех четырех операций CRUD (создание / чтение / обновление / удаление).
REST - это легкая альтернатива таким механизмам, как RPC (удаленные вызовы процедур) и веб-службы (SOAP, WSDL и др.). Позже мы увидим, насколько более простой REST.
Несмотря на простоту, REST полнофункциональный; В Web-сервисах практически ничего нельзя сделать, чего нельзя добиться с помощью архитектуры RESTful. ОТДЫХ не является "стандартом". Например, никогда не будет рекомендации W3C для REST. И хотя существуют среды программирования REST, работа с REST настолько проста, что вы часто можете "свернуть свои собственные" со стандартными библиотечными функциями на языках, таких как Perl, Java или C#.
Одна из лучших ссылок, которую я нашел, когда я пытаюсь найти простой реальный смысл отдыха.
REST использует различные методы HTTP (в основном, GET/PUT/DELETE) для манипулирования данными.
Вместо того, чтобы использовать определенный URL для удаления метода (скажем, /user/123/delete), вы бы отправили запрос на УДАЛЕНИЕ /user/[id] URL, для редактирования пользователя, для получения информации о пользователе, которому вы отправляете запрос GET /user/[id]
Например, вместо этого набор URL, который может выглядеть следующим образом:
GET /delete_user.x?id=123
GET /user/delete
GET /new_user.x
GET /user/new
GET /user?id=1
GET /user/id/1
Вы используете HTTP "глаголы" и имеете..
GET /user/2
DELETE /user/2
PUT /user
Это программирование, в котором архитектура вашей системы соответствует стилю REST, изложенному Роем Филдингом в его диссертации. Так как это архитектурный стиль, который описывает сеть (более или менее), многие люди заинтересованы в этом.
Дополнительный ответ: Нет. Если вы не изучаете архитектуру программного обеспечения в качестве академического или не разрабатываете веб-сервисы, нет никаких причин слышать этот термин.
Я бы сказал, что программирование RESTful будет о создании систем (API), которые следуют архитектурному стилю REST.
Я нашел этот фантастический, короткий и легкий для понимания урок о REST доктора М. Элькштейна и процитировал основную часть, которая ответит на ваш вопрос по большей части:
REST - это стиль архитектуры для проектирования сетевых приложений. Идея состоит в том, что вместо использования сложных механизмов, таких как CORBA, RPC или SOAP, для соединения между машинами, простой HTTP используется для выполнения вызовов между машинами.
- Во многих отношениях сама Всемирная паутина, основанная на HTTP, может рассматриваться как архитектура на основе REST.
Приложения RESTful используют HTTP-запросы для публикации данных (создания и / или обновления), чтения данных (например, создания запросов) и удаления данных. Таким образом, REST использует HTTP для всех четырех операций CRUD (создание / чтение / обновление / удаление).
Я не думаю, что вы должны чувствовать себя глупо, если не слышите о REST вне переполнения стека..., я бы попал в ту же ситуацию!; Ответы на этот другой вопрос о том, почему REST становится больше, могут ослабить некоторые чувства.
Я прошу прощения, если я не отвечаю на вопрос напрямую, но это легче понять с помощью более подробных примеров. Филдинг не легко понять из-за всей абстракции и терминологии.
Здесь есть довольно хороший пример:
Объяснение REST и гипертекста: Spam-E - робот для очистки от спама
И, что еще лучше, здесь есть простое объяснение с простыми примерами (PowerPoint более полный, но вы можете получить большую его часть в HTML-версии):
http://www.xfront.com/REST.ppt или http://www.xfront.com/REST.html
Прочитав примеры, я понял, почему Кен говорит, что REST управляется гипертекстом. На самом деле, я не уверен, что он прав, потому что /user/123 - это URI, который указывает на ресурс, и мне не ясно, что он НЕ УДАЛЕН только потому, что клиент знает об этом "вне диапазона".
Этот документ xfront объясняет разницу между REST и SOAP, и это тоже очень полезно. Когда Филдинг говорит: " Это RPC. Он кричит RPC", становится ясно, что RPC не RESTful, поэтому полезно выяснить точные причины этого. (SOAP - это тип RPC.)
Что такое ОТДЫХ?
REST, по официальным словам, REST - это архитектурный стиль, построенный на определенных принципах с использованием современных принципов "Интернета". Существует 5 основных веб-основ, которые используются для создания сервисов REST.
- Принцип 1. Все является ресурсом. В архитектурном стиле REST данные и функциональные возможности считаются ресурсами и доступны с использованием универсальных идентификаторов ресурсов (URI), обычно ссылок в Интернете.
- Принцип 2. Каждый ресурс идентифицируется уникальным идентификатором (URI).
- Принцип 3: используйте простые и унифицированные интерфейсы
- Принцип 4: Общение осуществляется представительством
- Принцип 5: не иметь гражданства
Я вижу кучу ответов, в которых говорится, что размещение всего о пользователе 123 на ресурсе "/user/123" - RESTful.
Рой Филдинг, который придумал этот термин, говорит, что API-интерфейсы REST должны основываться на гипертексте. В частности, "API REST не должен определять имена или иерархии фиксированных ресурсов".
Поэтому, если ваш путь "/user/123" жестко задан на клиенте, он не является действительно RESTful. Хорошее использование HTTP, может быть, а может и нет. Но не RESTful. Это должно исходить из гипертекста.
Ответ очень прост: есть диссертация, написанная Роем Филдингом.] 1 В этой диссертации он определяет принципы REST. Если приложение удовлетворяет всем этим принципам, то это приложение REST.
Термин RESTful был создан, потому что ppl исчерпал слово REST, назвав их не REST-приложение REST. После этого термин RESTful также был исчерпан. В настоящее время мы говорим о веб-API и гипермедиа-API, потому что большинство так называемых REST-приложений не удовлетворяли HATEOAS-части ограничения унифицированного интерфейса.
Ограничения REST следующие:
клиент-серверная архитектура
Так что он не работает, например, с разъемами PUB/SUB, он основан на REQ/REP.
связь без гражданства
Таким образом, сервер не поддерживает состояния клиентов. Это означает, что вы не можете использовать серверное хранилище сеансов, и вы должны аутентифицировать каждый запрос. Ваши клиенты могут отправлять основные заголовки аутентификации через зашифрованное соединение. (В больших приложениях трудно поддерживать много сессий.)
использование кеша, если вы можете
Таким образом, вам не нужно обслуживать одни и те же запросы снова и снова.
единый интерфейс как общий контракт между клиентом и сервером
Контракт между клиентом и сервером не поддерживается сервером. Другими словами, клиент должен быть отделен от реализации сервиса. Вы можете достичь этого состояния, используя стандартные решения, такие как стандарт IRI (URI) для идентификации ресурсов, стандарт HTTP для обмена сообщениями, стандартные типы MIME для описания формата сериализации тела, метаданные (возможно, RDF-выражения, микроформаты и т. Д.) Для опишите семантику различных частей тела сообщения. Чтобы отделить структуру IRI от клиента, необходимо отправить гиперссылки клиентам в гипермедиа форматах, таких как (HTML, JSON-LD, HAL и т. Д.). Таким образом, клиент может использовать метаданные (возможно, отношения ссылок, RDF-термины), назначенные гиперссылкам, для навигации конечного автомата приложения через надлежащие переходы состояний для достижения своей текущей цели.
Например, когда клиент хочет отправить заказ в интернет-магазин, он должен проверить гиперссылки в ответах, отправленных интернет-магазином. Проверяя ссылки, он находит ссылку, описанную с помощью http://schema.org/OrderAction. Клиент знает вокабу schema.org, поэтому он понимает, что, активировав эту гиперссылку, он отправит заказ. Таким образом, он активирует гиперссылку и отправляет
POST https://example.com/api/v1/orderсообщение с правильным телом. После этого служба обрабатывает сообщение и отвечает с результатом, имеющим правильный заголовок статуса HTTP, например201 - createdпо успеху. Для аннотирования сообщений подробными метаданными стандартное решение использовать формат RDF, например, JSON-LD с вокабом REST, например, Hydra и специфичные для домена вокабы, такие как http://schema.org/, или любой другой связанный со связью данных, и, возможно, пользовательский специфический для приложения вокабель, если необходимо. Теперь это непросто, поэтому большинство пользователей используют HAL и другие простые форматы, которые обычно предоставляют только REST vocab, но не поддерживают связанные данные.построить многоуровневую систему для повышения масштабируемости
Система REST состоит из иерархических слоев. Каждый уровень содержит компоненты, которые используют службы компонентов, которые находятся на следующем уровне ниже. Таким образом, вы можете добавлять новые слои и компоненты без особых усилий.
Например, есть уровень клиента, который содержит клиентов, а ниже уровень сервиса, который содержит один сервис. Теперь вы можете добавить кеш на стороне клиента между ними. После этого вы можете добавить другой экземпляр службы и балансировщик нагрузки и т. Д. Код клиента и код службы не изменятся.
код по требованию для расширения функциональности клиента
Это ограничение не является обязательным. Например, вы можете отправить синтаксический анализатор для определенного типа мультимедиа клиенту и т. Д.... Для этого вам может понадобиться стандартная система загрузчика плагинов в клиенте, или ваш клиент будет подключен к решению загрузчика плагинов,
Ограничения REST приводят к очень масштабируемой системе, в которой клиенты отделены от реализаций сервисов. Таким образом, клиенты могут быть повторно использованы, как и браузеры в Интернете. Клиенты и сервисы используют одни и те же стандарты и термины, поэтому они могут понимать друг друга, несмотря на то, что клиент не знает деталей реализации сервиса. Это позволяет создавать автоматизированных клиентов, которые могут находить и использовать службы REST для достижения своих целей. В долгосрочной перспективе эти клиенты могут общаться друг с другом и доверять друг другу задачи, как это делают люди. Если мы добавим шаблоны обучения для таких клиентов, то результатом будет один или несколько ИИ, использующих сеть машин вместо одного парка серверов. Так что в конце мечта Бернерса Ли: семантическая паутина и искусственный интеллект станут реальностью. Таким образом, в 2030 году мы были в конечном итоге уничтожены Скайнетом. До тех пор...;-)
API-интерфейс RESTful (передача состояния представления) - это написание веб-приложений на любом языке программирования с использованием следующих 5 основных принципов архитектурного стиля программного обеспечения:
- Ресурс (данные, информация).
- Уникальный глобальный идентификатор (все ресурсы уникально идентифицируются по URI).
- Единый интерфейс - используйте простой и стандартный интерфейс (HTTP).
- Представление - все общение осуществляется представлением (например, XML/ JSON)
- Без сохранения состояния (каждый запрос происходит в полной изоляции, кеширование и балансировка нагрузки легче),
Другими словами, вы пишете простые двухточечные сетевые приложения по HTTP, которые используют глаголы, такие как GET, POST, PUT или DELETE, внедряя архитектуру RESTful, которая предлагает стандартизацию интерфейса, предоставляемого каждым "ресурсом". Это ничто иное, как использование текущих возможностей Интернета простым и эффективным способом (очень успешная, проверенная и распределенная архитектура). Это альтернатива более сложным механизмам, таким как SOAP, CORBA и RPC.
Программирование RESTful соответствует дизайну веб-архитектуры и, при правильной реализации, позволяет использовать все преимущества масштабируемой веб-инфраструктуры.
Вот моя основная схема ОТДЫХА. Я попытался продемонстрировать мышление каждого из компонентов в архитектуре RESTful, чтобы понимание концепции было более интуитивным. Надеюсь, это поможет демистифицировать REST для некоторых людей!
REST (Transfer State Transfer) - это архитектура проекта, которая описывает, как сетевые ресурсы (то есть узлы, которые совместно используют информацию) проектируются и адресуются. В общем, архитектура RESTful делает так, чтобы клиент (запрашивающий компьютер) и сервер (отвечающий компьютер) могли запрашивать чтение, запись и обновление данных, при этом клиенту не нужно знать, как работает сервер, и сервер может пройти назад без необходимости знать что-либо о клиенте. Хорошо, круто... но как мы можем сделать это на практике?
Наиболее очевидным требованием является наличие какого-то универсального языка, чтобы сервер мог сообщить клиенту, что он пытается сделать с запросом, и чтобы сервер ответил.
Но чтобы найти какой-либо конкретный ресурс, а затем сообщить клиенту, где он находится, необходим универсальный способ указания ресурсов. Это где универсальные идентификаторы ресурсов (URI) приходят; это в основном уникальные адреса для поиска ресурсов.
Но архитектура REST на этом не заканчивается! Хотя вышеперечисленное удовлетворяет основные потребности того, что мы хотим, мы также хотим иметь архитектуру, которая поддерживает большой объем трафика, поскольку любой данный сервер обычно обрабатывает ответы от ряда клиентов. Таким образом, мы не хотим перегружать сервер, заставляя его запоминать информацию о предыдущих запросах.
Поэтому мы налагаем ограничение на то, что каждая пара запрос-ответ между клиентом и сервером является независимой, что означает, что серверу не нужно ничего запоминать о предыдущих запросах (предыдущих состояниях взаимодействия клиент-сервер), чтобы ответить на новый запрос. Это означает, что мы хотим, чтобы наши взаимодействия не имели состояния.
Чтобы еще больше облегчить нагрузку на наш сервер от повторения вычислений, которые недавно были выполнены для данного клиента, REST также разрешает кэширование. По сути, кэширование означает создание моментального снимка исходного ответа, предоставленного клиенту. Если клиент делает тот же запрос снова, сервер может предоставить клиенту моментальный снимок, а не повторять все вычисления, которые были необходимы для создания начального ответа. Однако, поскольку это моментальный снимок, если моментальный снимок не истек - сервер заранее устанавливает время истечения - и ответ был обновлен с момента первоначального кэша (т. Е. Запрос дал бы ответ, отличный от кэшированного ответа) клиент не увидит обновления до тех пор, пока не истечет срок действия кеша (или кеш не будет очищен) и ответ не будет обработан заново.
Последнее, что вы часто будете здесь о архитектурах RESTful, - это их многоуровневость. На самом деле мы уже неявно обсуждали это требование в нашем обсуждении взаимодействия между клиентом и сервером. По сути, это означает, что каждый слой в нашей системе взаимодействует только с соседними слоями. Таким образом, в нашем обсуждении уровень клиента взаимодействует с уровнем нашего сервера (и наоборот), но могут быть и другие уровни сервера, которые помогают основному серверу обрабатывать запрос, с которым клиент не связывается напрямую. Скорее, сервер передает запрос по мере необходимости.
Теперь, если все это звучит знакомо, тогда замечательно. Протокол передачи гипертекста (HTTP), который определяет протокол связи через World Wide Web, является реализацией абстрактного понятия архитектуры RESTful (или экземпляра класса REST, если вы фанат ООП, как я). В этой реализации REST клиент и сервер взаимодействуют через GET, POST, PUT, DELETE и т. Д., Которые являются частью универсального языка, и ресурсы можно указывать с помощью URL-адресов.
Если бы мне пришлось сократить первоначальную диссертацию по REST до 3 коротких предложений, я думаю, что следующее отражает ее суть:
- Ресурсы запрашиваются через URL.
- Протоколы ограничены тем, что вы можете общаться с помощью URL-адресов.
- Метаданные передаются в виде пар имя-значение (данные публикации и параметры строки запроса).
После этого легко начать дискуссию об адаптациях, соглашениях о кодировании и передовых методах.
Интересно, что в диссертации нет упоминаний об операциях HTTP POST, GET, DELETE или PUT. Это должно быть чье-то позднее толкование "лучшей практики" для "единого интерфейса".
Когда дело доходит до веб-сервисов, нам кажется, что нам нужен какой-то способ различения архитектур на основе WSDL и SOAP, которые добавляют значительные накладные расходы и, возможно, много ненужной сложности интерфейса. Они также требуют дополнительных структур и инструментов разработчика для реализации. Я не уверен, является ли REST лучшим термином для разграничения между интерфейсами здравого смысла и чрезмерно разработанными интерфейсами, такими как WSDL и SOAP. Но нам нужно что-то.
REST - это архитектурный паттерн и стиль написания распределенных приложений. Это не стиль программирования в узком смысле.
Сказать, что вы используете стиль REST - это то же самое, что сказать, что вы построили дом в определенном стиле: например, в стиле Тюдоров или в викторианском стиле. И REST как стиль программного обеспечения, и Tudor или викторианский как стиль дома могут быть определены качествами и ограничениями, которые их составляют. Например, REST должен иметь разделение Client Server, где сообщения имеют самоописание. Дома в стиле Тюдор имеют перекрывающие фронтоны и крыши, которые имеют крутой наклон фронтонов. Вы можете прочитать диссертацию Роя, чтобы узнать больше об ограничениях и качествах, которые составляют ОТДЫХ.
REST, в отличие от домашних стилей, испытывал трудности с последовательным и практическим применением. Это могло быть преднамеренным. Оставляя его актуальную реализацию до дизайнера. Таким образом, вы можете делать то, что вы хотите, если вы соответствуете ограничениям, изложенным в диссертации, которую вы создаете.
Бонус:
Вся сеть основана на REST (или REST была основана на сети). Поэтому, как веб-разработчик, вы можете знать об этом, хотя писать хорошие веб-приложения не обязательно.
Я думаю, что смысл restful - это разделение состояния на более высокий уровень при использовании Интернета (протокола) в качестве транспортного уровня без сохранения состояния. Большинство других подходов перемешивают.
Это был лучший практический подход, чтобы справиться с фундаментальными изменениями программирования в эпоху Интернета. Что касается фундаментальных изменений, Эрик Мейер обсуждает это здесь: http://www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity. Он суммирует это как пять эффектов и представляет решение, проектируя решение в язык программирования. Решение также может быть достигнуто на уровне платформы или системы, независимо от языка. Отдых может рассматриваться как одно из решений, которое было очень успешным в современной практике.
С спокойным стилем вы получаете и управляете состоянием приложения через ненадежный интернет. Если текущей операции не удается получить правильное и текущее состояние, ему необходим принцип нулевой проверки, чтобы приложение могло продолжить работу. Если он не может манипулировать состоянием, он обычно использует несколько этапов подтверждения, чтобы все было правильно. В этом смысле отдых сам по себе не является целым решением, ему нужны функции в другой части стека веб-приложений для поддержки его работы.
Учитывая эту точку зрения, стиль отдыха на самом деле не привязан к интернету или веб-приложению. Это фундаментальное решение для многих ситуаций программирования. Это также не просто, это просто делает интерфейс действительно простым и удивительно хорошо справляется с другими технологиями.
Просто мой 2с.
Изменить: два более важных аспекта:
Безгражданство вводит в заблуждение. Речь идет об остальном API, а не о приложении или системе. Система должна быть с состоянием. Restful design - это проектирование системы с сохранением состояния на основе API без сохранения состояния. Некоторые цитаты из другого QA:
- REST работает с представлениями ресурсов, каждое из которых идентифицируется URL. Обычно это не объекты данных, а абстракции сложных объектов.
- REST расшифровывается как "передача состояния репрезентации", что означает передачу и изменение состояния некоторого ресурса в системе.
Идемпотентность: часто пропускаемая часть REST - идемпотентность большинства глаголов. Это приводит к надежным системам и меньшей взаимозависимости точных интерпретаций семантики.
Старый вопрос, новый способ ответа. Есть много заблуждений об этой концепции. Я всегда стараюсь запомнить:
- Структурированные URL-адреса и методы / глаголы Http не являются определением спокойного программирования.
- JSON - это не спокойное программирование
- RESTful программирование не для API
Я определяю спокойное программирование как
Приложение успокаивается, если оно предоставляет ресурсы (являющиеся комбинацией элементов управления данными + переходы состояний) в типе носителя, который понимает клиент
Чтобы быть спокойным программистом, вы должны пытаться создавать приложения, позволяющие актерам делать что-то. Не только разоблачение базы данных.
Элементы управления переходом между состояниями имеют смысл только в том случае, если клиент и сервер договариваются о представлении ресурса по типу носителя. В противном случае нет способа узнать, что такое элемент управления, а что нет, и как выполнить элемент управления. То есть, если браузеры не знают тегов в html, вам нечего будет отправлять в переходное состояние в вашем браузере.
Я не стремлюсь к саморекламе, но я углубляюсь в эти идеи в своем выступлении http://techblog.bodybuilding.com/2016/01/video-what-is-restful-200.html.
REST определяет 6 архитектурных ограничений, которые делают любой веб-сервис - настоящий RESTful API.
- Единый интерфейс
- Клиент-сервер
- Stateless
- Cacheable
- Многоуровневая система
- Код по запросу (необязательно)
Это удивительно долгая "дискуссия" и все же довольно запутанная, если не сказать больше.
IMO:
1) нет такой вещи, как спокойное программирование, без большого сустава и большого количества пива:)
2) Передача представительского состояния (REST) - это архитектурный стиль, указанный в диссертации Роя Филдинга. Это имеет ряд ограничений. Если ваш Сервис / Клиент уважает их, тогда это RESTful. Это оно.
Вы можете суммировать (значительно) ограничения на:
- связь без гражданства
- соблюдайте спецификации HTTP (если используется HTTP)
- четко передает передаваемые форматы контента
- использовать гипермедиа как движок состояния приложения
Есть еще один очень хороший пост, который хорошо объясняет.
Многие ответы копируют / вставляют достоверную информацию, смешивая ее и добавляя некоторую путаницу. Люди говорят здесь об уровнях, об RESTFul URI (нет такого!), Применяют методы HTTP GET,POST,PUT ... REST не об этом или не только об этом.
Например, ссылки - это приятно иметь красиво выглядящий API, но в конце клиент / сервер на самом деле не заботится о ссылках, которые вы получаете / отправляете, это контент, который имеет значение.
В конце концов, любой клиент RESTful должен иметь возможность использовать любой сервис RESTful, пока известен формат контента.
Этот ответ для абсолютных новичков, давайте узнаем о наиболее часто используемых сегодня архитектурах API.
Чтобы понять Restful-программирование или Restful API. Во-первых, вы должны понять, что такое API, на очень высоком уровне API означает интерфейс прикладного программирования, это в основном часть программного обеспечения, которое может использоваться другой частью программного обеспечения, чтобы приложения могли общаться друг с другом.
Наиболее широко используемый тип API в мире - это веб-API, в то время как приложение, которое отправляет данные клиенту при каждом поступлении запроса.
Фактически, API используются не только для отправки данных и не всегда связаны с веб-разработкой, javascript, python или каким-либо языком программирования или фреймворком.
The application in API can actually mean many different things as long as the pice of software is relatively stand-alone. Take for example, the File System or the HTTP Modules we can say that they are small pieces of software and we can use them, we can interact with them by using their API. For example when we use the read file function for a file system module of any programming language, we are actually using the file_system_reading API. Or when we do DOM manipulation in the browser, we're are not really using the JavaScript language itself, but rather, the DOM API that browser exposes to us, so it gives us access to it. Or even another example let's say we create a class in any programming language like Java and then add some public methods or properties to it, these methods will then be the API of each object created from that class because we are giving other pieces of software the possibility of interacting with our initial piece of software, the objects in this case. S0, API has actually a broader meaning than just building web APIs.
Now let's take a look at the REST Architecture to build APIs.
REST which stands for Representational State Transfer is basically a way of building web APIs in a logical way, making them easy to consume for ourselves or for others.
To build Restful APIs following the REST Architecture, we just need to follow a couple of principles. 1. We need to separate our API into logical resources. 2. These resources should then be exposed by using resource-based URLs. 3. To perform different actions on data like reading, creating, or deleting data the API should use the right HTTP methods and not the URL. 4. Now the data that we actually send back to the client or that we received from the client should usually use the JSON data format, were some formatting standard applied to it. 5. Finally, another important principle of EST APIs is that they must be stateless.
Разделите API-интерфейсы на логические ресурсы: ключевая абстракция информации в REST - это ресурс, и поэтому все данные, которыми мы хотим поделиться в API, должны быть разделены на логические ресурсы. Что на самом деле представляет собой ресурс? Что ж, в контексте REST это объект или представление чего-либо, с которым связаны некоторые данные. Например, такие приложения, как туры с гидом, или пользователи, места или обзоры, являются примером логических ресурсов. Таким образом, практически любая информация, которую можно назвать, может быть ресурсом. Просто надо назвать, а не глагол.
Раскрытие структуры: теперь нам нужно раскрыть, что означает сделать доступными данные, используя некоторые структурированные URL-адреса, на которые клиент может отправить запрос. Например, что-то вроде этого всего адреса называется URL-адресом. и этот / addNewTour называется конечной точкой API.
У нашего API будет много разных конечных точек, как показано ниже.
https://www.tourguide.com/addNewTour
https://www.tourguide.com/getTour
https://www.tourguide.com/updateTour
https://www.tourguide.com/deleteTour
https://www.tourguide.com/getRoursByUser
https://www.tourguide.com/deleteToursByUser
Каждый из этих API будет отправлять разные данные клиенту, а также выполнять разные действия. Здесь что-то очень не так с этими конечными точками, потому что они действительно не следуют третьему правилу, которое гласит, что мы должны использовать только методы HTTP для выполнения действий с данными. Таким образом, конечные точки должны содержать только наши ресурсы, а не действия, которые мы выполняем над ними, потому что их обслуживание быстро станет кошмаром.
Как нам использовать эти HTTP-методы на практике? Что ж, давайте посмотрим, как эти конечные точки должны выглядеть, начиная с / getTour. Таким образом, эта конечная точка getTour предназначена для получения данных о туре, поэтому мы должны просто назвать конечную точку / туры и отправлять данные всякий раз, когда к этой конечной точке делается запрос на получение. Другими словами, когда клиент использует метод GET HTTP для доступа к конечной точке,
(у нас есть ресурсы только в конечной точке или в URL-адресе и нет глаголов, потому что глагол теперь находится в методе HTTP, верно? Обычная практика - всегда использовать имя ресурса во множественном числе, поэтому я написал / tours или / tour. Соглашение заключается в том, что при вызове конечной точки / Tours будут возвращены все туры, которые есть в базе данных, но если нам нужен тур только с одним идентификатором, скажем, с семью, мы добавляем эти семь после другого слэша (/tours/7) или в поисковом запросе (/tours?id=7), и, конечно же, это также могло быть название тура вместо идентификатора.
Методы HTTP: что действительно важно, так это то, что имя конечной точки является одним и тем же именем для всех.
GET: (for requesting data from the server.)
https://www.tourguide.com/tours/7
POST: (for sending data to the server.)
https://www.tourguide.com/tours
PUT/PATCH: (for updating requests for data to the server.) https://www.tourguide.com/tours/7
DELETE: (for deleting request for data to the server.)
https://www.tourguide.com/tours/7
Разница между PUT и PATCH-> Используя PUT, клиент должен отправить весь обновленный объект, в то время как с PATCH он должен отправить только ту часть объекта, которая была изменена.
Используя методы HTTP, пользователи могут выполнять четыре основные операции CRUD, CRUD означает создание, чтение, обновление и удаление.
Теперь может возникнуть ситуация, подобная приведенной ниже:
Итак, /getToursByUser можно просто перевести в /users/tours, для конечной точки пользователя номер 3 будет выглядеть /users/3/tours.
если мы хотим удалить конкретный тур определенного пользователя, тогда URL-адрес должен быть таким, как /users/3/tours/7, здесь идентификатор пользователя:3 и идентификатор тура: 7.
Так что действительно существует масса возможностей для подобного объединения ресурсов.
Отправлять данные как JSON: Теперь о данных, которые фактически получает клиент или которые сервер получает от клиента, обычно мы используем формат данных JSON. Типичный JSON может выглядеть следующим образом: Перед отправкой данных JSON мы обычно выполняем простое форматирование ответа, для этого существует несколько стандартов, но один из самых простых - Jsend. Мы просто создаем новый объект, а затем добавляем к нему статусное сообщение, чтобы сообщить клиенту, был ли запрос успешным, неудачным или ошибочным. А затем мы помещаем наши исходные данные в новый объект с именем Data.
Обертывание данных в дополнительный объект, как мы сделали здесь, называется Enveloping, и это обычная практика для смягчения некоторых проблем безопасности и других проблем.
Restful API всегда должен быть без состояния: наконец, RESTful API всегда должен быть без состояния, что означает, что в RESTful API без сохранения состояния все состояние обрабатывается на стороне клиента, а не на сервере. А состояние просто относится к фрагменту данных в приложении, который может изменяться со временем. Например, вошел ли определенный пользователь в систему или находится на странице со списком из нескольких страниц, какова текущая страница? Теперь тот факт, что состояние должно обрабатываться на клиенте, означает, что каждый запрос должен содержать всю информацию, необходимую для обработки определенного запроса на сервере. Таким образом, серверу никогда не нужно запоминать предыдущий запрос, чтобы обработать текущий запрос.
Предположим, что сейчас мы находимся на пятой странице и хотим перейти к шестой странице. Итак, мы могли бы иметь простую конечную точку с именем / tours / nextPage и отправлять запрос на сервер, но затем сервер должен был бы выяснить, что такое текущая страница, и на основе этого сервера отправит следующую страницу клиенту. Другими словами, сервер должен запомнить предыдущий запрос. Это именно то, чего мы хотим избежать в RESTful API.
Вместо этого мы должны создать конечную точку /tours/page и вставить в нее номер шесть, чтобы запросить страницу с номером шесть /tours/page/6 . Таким образом, серверу не нужно ничего запоминать, все, что ему нужно сделать, это отправить обратно данные для страницы номер шесть, как мы просили.
Безгражданство и противоположное состояние - очень важные концепции в информатике и приложениях в целом.
REST === HTTP-аналог не верен до тех пор, пока вы не подчеркнете тот факт, что он "ДОЛЖЕН" управляться HATEOAS.
Рой сам очистил это здесь.
API REST следует вводить без каких-либо предварительных знаний, кроме начального URI (закладки) и набора стандартизированных типов мультимедиа, подходящих для целевой аудитории (то есть ожидается, что их поймет любой клиент, который может использовать API). С этого момента все переходы состояния приложения должны определяться выбором клиентом предоставленных сервером вариантов, которые присутствуют в полученных представлениях или подразумеваются манипуляциями пользователя с этими представлениями. Переходы могут быть определены (или ограничены) знаниями клиента о типах мультимедиа и механизмах связи с ресурсами, которые могут быть улучшены на лету (например, код по запросу).
[Ошибка здесь подразумевает, что внешняя информация является движущей силой взаимодействия, а не гипертекста.]
REST - это архитектурный стиль, основанный на веб-стандартах и протоколе HTTP (представлен в 2000 году).
В архитектуре на основе REST все является ресурсом (пользователи, заказы, комментарии). Доступ к ресурсу осуществляется через общий интерфейс на основе стандартных методов HTTP (GET, PUT, PATCH, DELETE и т. Д.).
В архитектуре на основе REST у вас есть сервер REST, который обеспечивает доступ к ресурсам. Клиент REST может получить доступ и изменить ресурсы REST.
Каждый ресурс должен поддерживать общие операции HTTP. Ресурсы идентифицируются глобальными идентификаторами (которые обычно являются URI).
REST позволяет ресурсам иметь разные представления, например, текст, XML, JSON и т. Д. Клиент REST может запрашивать конкретное представление через протокол HTTP (согласование содержимого).
HTTP методы:
Методы PUT, GET, POST и DELETE типично используются в архитектурах на основе REST. Следующая таблица дает объяснение этих операций.
- GET определяет доступ для чтения ресурса без побочных эффектов. Ресурс никогда не изменяется с помощью запроса GET, например, запрос не имеет побочных эффектов (идемпотент).
- PUT создает новый ресурс. Он также должен быть идемпотентом.
- DELETE удаляет ресурсы. Операции идемпотентны. Они могут повторяться, не приводя к разным результатам.
- POST обновляет существующий ресурс или создает новый ресурс.
Разговор - это не просто обмен информацией. Протокол на самом деле разработан таким образом, чтобы не было разговоров. Каждая сторона знает, какова их конкретная работа, потому что это указано в протоколе. Протоколы позволяют осуществлять чистый обмен информацией за счет каких-либо изменений возможных действий. Разговор, с другой стороны, позволяет одной стороне спросить, какие дальнейшие действия могут быть предприняты другой стороной. Они могут даже задать один и тот же вопрос дважды и получить два разных ответа, поскольку за это время состояние другой стороны могло измениться. Разговор - это ОТЛИЧНАЯ архитектура. Тезис Филдинга определяет архитектуру, которой нужно было бы следовать, если бы человек хотел, чтобы машины общались друг с другом, а не просто общались.
REST расшифровывается как представительский государственный перевод.
Он основывается на протоколе обмена данными между клиентом и сервером, не зависящем от состояния, и практически во всех случаях используется протокол HTTP.
REST часто используется в мобильных приложениях, веб-сайтах социальных сетей, инструментах гибридов и автоматизированных бизнес-процессах. Стиль REST подчеркивает, что взаимодействие между клиентами и сервисами улучшается благодаря ограниченному количеству операций (глаголов). Гибкость обеспечивается назначением ресурсов (существительных) их собственных уникальных универсальных индикаторов ресурсов (URI).
Само по себе понятия "программирование RESTful" не существует. Лучше было бы назвать парадигму RESTful или даже лучше архитектуру RESTful. Это не язык программирования. Это парадигма.
В вычислениях передача состояния представления (REST) - это архитектурный стиль, используемый для веб-разработки.
Дело в том, что если мы согласимся использовать общий язык для базовых операций (глаголы http), инфраструктура может быть настроена для их понимания и оптимизации, например, путем использования заголовков кэширования для реализации кэширования вообще уровни.
При правильно реализованной операции restful GET не должно иметь значения, поступает ли информация из БД вашего сервера, из кэша вашего сервера, из CDN, из кэша прокси, из кэша вашего браузера или из локального хранилища вашего браузера. Можно использовать самый быстрый, самый доступный на сегодняшний день источник.
Сказать, что Rest - это всего лишь синтаксическое изменение от использования запросов GET с параметром action к использованию доступных HTTP-глаголов, и это выглядит так, как будто оно не имеет никаких преимуществ и является чисто косметическим. Суть в том, чтобы использовать язык, который может быть понят и оптимизирован каждой частью цепочки. Если ваша операция GET имеет действие с побочными эффектами, вам придется пропустить все HTTP-кэширование, иначе вы получите противоречивые результаты.
Что такое API-тестирование?
Тестирование API использует программирование для отправки вызовов API и получения дохода. Тестирование рассматривает тестируемый сегмент как черный ящик. Цель тестирования API - подтвердить правильность выполнения и грубую обработку части, предшествующей ее согласованию в приложении.
REST API
ОТДЫХ: Представительский государственный трансферт.
- Это набор функций, по которым тестеры выполняют запросы и получают ответы. В REST API взаимодействие осуществляется по протоколу HTTP.
- REST также разрешает связь между компьютерами по сети.
- Для отправки и получения сообщений он использует методы HTTP и не требует строгого определения сообщения, в отличие от веб-служб.
- Сообщения REST часто принимают форму в форме XML или JavaScript Object Notation (JSON).
4 Обычно используемые методы API:-
- GET:- Предоставляет доступ только для чтения к ресурсу.
- POST:- Он используется для создания или обновления нового ресурса.
- PUT:- используется для обновления или замены существующего ресурса или создания нового ресурса.
- УДАЛИТЬ:- Используется для удаления ресурса.
Шаги для тестирования API вручную:-
Чтобы использовать API вручную, мы можем использовать браузерные плагины REST API.
- Установите плагин POSTMAN(Chrome) / REST(Firefox)
- Введите URL API
- Выберите метод REST
- Выберите заголовок контента
- Введите запрос JSON (POST)
- Нажмите на отправить
- Он вернет ответ
Это очень редко упоминается повсюду, но модель зрелости Ричардсона является одним из лучших методов, позволяющих судить, насколько Restful является API. Подробнее об этом здесь: