it-roy-ru.com

Что такое RESTful-программирование?

Что такое RESTful-программирование?

3761
hasen

Архитектурный стиль, называемый 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 face книга.

619
Shirgill Farhan

REST является основным архитектурным принципом сети. Удивительной вещью в Интернете является тот факт, что клиенты (браузеры) и серверы могут взаимодействовать сложным образом, при этом клиент ничего не знает заранее о сервере и размещенных на нем ресурсах. Основное ограничение заключается в том, что сервер и клиент должны согласовать используемое media, которое в случае с веб-интерфейсом - 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 обычно реализовывалось несколькими несколько лет назад, когда я впервые написал это, а не его истинное значение. Я пересмотрел ответ, чтобы лучше представить реальное значение.)

2842
Emil H

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 и интерфейсы передачи сообщений являются масштабируемыми.

Я думаю, что наиболее важная уловка для понимания архитектурной важности и влияний на производительность архитектур RESTful и Shared Nothing состоит в том, чтобы не зацикливаться на деталях технологии и реализации. Сконцентрируйтесь на том, кому принадлежат ресурсы, кто отвечает за их создание/обслуживание и т.д. Затем подумайте о представлениях, протоколах и технологиях.

514
D.Shawley

Вот как это может выглядеть.

Создайте пользователя с тремя свойствами:

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
401
pbreitenbach

Отличная книга по REST - REST на практике .

Должны быть прочитаны API представления представительного состояния (REST) ​​ и REST, управляемые гипертекстом

См. Статью Мартина Фаулерса Модель зрелости Ричардсона (RMM) для объяснения того, что такое служба RESTful. 

Richardson Maturity Model

Чтобы быть RESTful, Служба должна выполнять Hypermedia как Механизм Состояния Приложения. (HATEOAS) , то есть он должен достичь уровня 3 в RMM, для подробностей прочитайте статью или слайды из выступления qcon .

Ограничение HATEOAS является аббревиатурой для Гипермедиа как Двигатель Состояние приложения. Этот принцип ключевое различие между ОТДЫХОМ и большинство других форм клиентского сервера система.

...

Клиент RESTful-приложения нуждается знать только один фиксированный URL для доступа Это. Все будущие действия должны быть обнаруживается динамически из гиперссылки включены в представления ресурсов, которые возвращаются с этого URL . Стандартизированные типы носителей также Ожидается, что будет понят любой клиент, который может использовать RESTful API. (Из Википедии, свободной энциклопедии)

REST Лакмусовый тест для веб-фреймворков - аналогичный тест на зрелость для веб-фреймворков.

Приближаемся к чистому ОТДЫХУ: Учимся любить HATEOAS - это хорошая коллекция ссылок. 

REST и SOAP для публичного облака обсуждают текущие уровни использования REST. 

REST и версия обсуждают расширяемость, управление версиями, эволюционируемость и т.д через модифицируемость

176
oluies

Что такое ОТДЫХ?

REST расшифровывается как представительский государственный трансферт. (Иногда это Пишется "ReST".) Он опирается на клиент-сервер без кэша, кешируемый протокол связи - и практически во всех случаях HTTP протокол используется.

REST - это архитектурный стиль для проектирования сетевых приложений. Идея заключается в том, что вместо использования сложных механизмов, таких как CORBA, RPC или SOAP для соединения между машинами, простой HTTP используется для создания звонки между машинами.

Во многих отношениях сама всемирная паутина, основанная на HTTP, может быть просмотрена как основанная на REST архитектура. Приложения RESTful используют HTTP-запросы размещать данные (создавать и/или обновлять), читать данные (например, делать запросы), и удалить данные. Таким образом, REST использует HTTP для всех четырех CRUD Операции (создание/чтение/обновление/удаление).

REST - это легкая альтернатива таким механизмам, как RPC (удаленные вызовы процедур .__) и веб-службы (SOAP, WSDL и др.). Позже мы будем посмотрим, насколько проще REST.

Несмотря на простоту, REST полнофункциональный; есть в основном ничего, что вы не можете сделать в веб-службах, что нельзя сделать с помощью RESTful архитектура. REST не является «стандартом». Там никогда не будет W3C например, рекомендация для ОТДЫХА. А пока есть ОТДЫХ рамки программирования, работа с REST настолько проста, что вы можете часто "катайся сам" со стандартными функциями библиотеки на таких языках, как Perl, Java или C #.

Одна из лучших ссылок, которую я нашел, когда я пытаюсь найти простой реальный смысл отдыха.

http://rest.elkstein.org/

132
Ravi

REST использует различные методы HTTP (в основном, GET/PUT/DELETE) для манипулирования данными.

Вместо использования определенного URL-адреса для удаления метода (скажем, /user/123/delete), вы бы отправили запрос DELETE на URL-адрес /user/[id], чтобы отредактировать пользователя, чтобы получить информацию о пользователе, которому вы отправили запрос 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
88
dbr

Это программирование, в котором архитектура вашей системы соответствует стилю REST изложенному Роем Филдингом в его диссертации . Так как это архитектурный стиль, который описывает сеть (более или менее), многие люди заинтересованы в этом.

Дополнительный ответ: Нет. Если вы не изучаете архитектуру программного обеспечения как академическое или не разрабатываете веб-сервисы, нет никаких причин слышать этот термин.

67
Hank Gay

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

Здесь есть довольно хороший пример:

Объяснение 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.)

45
tompark

Я бы сказал, что программирование RESTful будет о создании систем (API), которые следуют архитектурному стилю REST.

Я нашел этот фантастический, короткий и легкий для понимания урок о REST доктора М. Элькштейна и процитировал основную часть, которая ответила бы на ваш вопрос по большей части:

Изучите ОТДЫХ: Учебное пособие

REST - это архитектура стиля для проектирования сетевых приложений . Идея заключается в том, что вместо использования сложных механизмов, таких как CORBA, RPC или SOAP для соединения между машинами, простой HTTP используется для создания звонки между машинами.

  • Во многих отношениях сама Всемирная паутина, основанная на HTTP, может рассматриваться как архитектура на основе REST.

Приложения RESTful используют HTTP-запросы для публикации данных (создания и/или Обновления), чтения данных (например, выполнения запросов) и удаления данных. Таким образом, REST использует HTTP для всех четырех операций CRUD (создание/чтение/обновление/удаление).

Я не думаю, что вы должны чувствовать себя глупо, если не слышите о REST вне переполнения стека ..., я бы попал в ту же ситуацию !; ответы на этот другой SO вопрос о Почему REST становится больше может ослабить некоторые чувства.

44
Only You

Что такое ОТДЫХ?

REST, по официальным словам, REST - это архитектурный стиль, построенный на определенных принципах, использующих текущие «веб-основы» Существует 5 основных принципов веб-технологий, которые используются для создания REST сервисов.

  • Принцип 1. Все является ресурсом. В архитектурном стиле REST данные и функциональные возможности считаются ресурсами и доступны с использованием универсальных идентификаторов ресурсов (URI), обычно ссылок в Интернете.
  • Принцип 2. Каждый ресурс идентифицируется уникальным идентификатором (URI).
  • Принцип 3: используйте простые и унифицированные интерфейсы
  • Принцип 4: Общение осуществляется представительством
  • Принцип 5: не иметь гражданства 
37
Suresh Gupta

Я вижу кучу ответов, которые говорят, что помещать все о пользователе 123 в ресурс "/ user/123" - RESTful.

Рой Филдинг, который придумал этот термин, говорит, что REST API должны управляться гипертекстом . В частности, «API REST не должен определять фиксированные имена ресурсов или иерархии».

Поэтому, если ваш путь "/ user/123" жестко задан на клиенте, он не является действительно RESTful. Хорошее использование HTTP, может быть, а может и нет. Но не RESTful. Это должно исходить из гипертекста.

34
Ken

Ответ очень прост, есть диссертация написанная Роем Филдингом.] 1 В этой диссертации он определяет принципы REST. Если приложение удовлетворяет всем этим принципам, то это приложение REST.

Термин RESTful был создан, потому что ppl исчерпал Word REST, вызвав их не REST-приложение как REST. После этого термин RESTful также был исчерпан. В настоящее время мы говорим о Web API и Hypermedia API , потому что большинство так называемых REST приложений не удовлетворяли части HATEOAS ограничения унифицированного интерфейса.

REST следующие ограничения:

  1. клиент-серверная архитектура

    Так что он не работает, например, с разъемами PUB/SUB, он основан на REQ/REP.

  2. связь без гражданства

    Таким образом, сервер не поддерживает состояния клиентов. Это означает, что вы не можете использовать серверное хранилище сеансов, и вы должны аутентифицировать каждый запрос. Ваши клиенты могут отправлять основные заголовки аутентификации через зашифрованное соединение. (В больших приложениях трудно поддерживать много сессий.)

  3. использование кеша, если вы можете

    Таким образом, вам не нужно обслуживать одни и те же запросы снова и снова.

  4. единый интерфейс как общий контракт между клиентом и сервером

    Контракт между клиентом и сервером не поддерживается сервером. Другими словами, клиент должен быть отделен от реализации сервиса. Вы можете достичь этого состояния с помощью стандартных решений, таких как стандарт IRI (URI) для идентификации ресурсов, стандарт HTTP для обмена сообщениями, стандартные типы MIME для описания формата сериализации тела, метаданные (возможно, RDF vocabs, микроформаты, и т.д.) для описания семантики различных частей тела сообщения. Чтобы отделить структуру 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 и специфичные для домена вокабы, такие как schema.org или любой другой связанный словарь данных и, возможно, пользовательский словарь для конкретного приложения, если это необходимо. Теперь это непросто, поэтому большинство пользователей используют HAL и другие простые форматы, которые обычно предоставляют только REST вокаб, но не поддерживают связанные данные.

  5. построить многоуровневую систему для повышения масштабируемости

    Система REST состоит из иерархических слоев. Каждый уровень содержит компоненты, которые используют службы компонентов, которые находятся на следующем уровне ниже. Таким образом, вы можете добавлять новые слои и компоненты без особых усилий. 

    Например, существует уровень клиента, который содержит клиентов, а ниже - уровень службы, который содержит одну службу. Теперь вы можете добавить кеш на стороне клиента между ними. После этого вы можете добавить еще один экземпляр службы, балансировщик нагрузки и т.д. Код клиента и код службы не изменятся.

  6. код по требованию для расширения функциональности клиента

    Это ограничение не является обязательным. Например, вы можете отправить синтаксический анализатор для определенного типа мультимедиа клиенту и т.д. ... Для этого вам может потребоваться стандартная система загрузчика плагинов в клиенте, или ваш клиент будет подключен к решению загрузчика плагинов ,.

Ограничения REST приводят к очень масштабируемой системе, в которой клиенты отделены от реализаций сервисов. Таким образом, клиенты могут быть повторно использованы, как и браузеры в Интернете. Клиенты и сервисы используют одни и те же стандарты и термины, поэтому они могут понимать друг друга, несмотря на то, что клиент не знает деталей реализации сервиса. Это позволяет создавать автоматизированных клиентов, которые могут находить и использовать REST сервисы для достижения своих целей. В долгосрочной перспективе эти клиенты могут общаться друг с другом и доверять друг другу задачи, как это делают люди. Если мы добавим шаблоны обучения для таких клиентов, то результатом будет один или несколько ИИ, использующих сеть машин вместо одного парка серверов. Так что в конце мечта Бернерса Ли: семантическая паутина и искусственный интеллект станут реальностью. Таким образом, в 2030 году мы в конечном итоге уничтожены Скайнетом. До тех пор ... ;-)

26
inf3rno

RESTful (Передача состояния представления) API-программирование - это написание веб-приложений на любом языке программирования с использованием следующих 5 основных программных средств архитектурный стиль принципы:

  1. Ресурс (данные, информация).
  2. Уникальный глобальный идентификатор (все ресурсы уникально идентифицируются с помощью URI ).
  3. Единый интерфейс - использовать простой и стандартный интерфейс (HTTP).
  4. Представление - все общение осуществляется представлением (например, XML / JSON )
  5. без состояния (каждый запрос происходит в полной изоляции, кеширование и балансировка нагрузки проще),

Другими словами, вы пишете простые двухточечные сетевые приложения по HTTP, которые используют глаголы, такие как GET, POST, PUT или DELETE, внедряя архитектуру RESTful, которая предлагает стандартизацию интерфейса, предоставляемого каждым «ресурсом». Это ничто иное, как использование текущих возможностей Интернета простым и эффективным способом (очень успешная, проверенная и распределенная архитектура). Это альтернатива более сложным механизмам, таким как SOAP , CORBA и RPC

Программирование RESTful соответствует дизайну веб-архитектуры и, при правильной реализации, позволяет использовать все преимущества масштабируемой веб-инфраструктуры.

20
kenorb

Если бы мне пришлось сократить первоначальную диссертацию по REST до трех коротких предложений, я думаю, что следующее отражает ее суть:

  1. Ресурсы запрашиваются через URL.
  2. Протоколы ограничены тем, что вы можете общаться с помощью URL-адресов.
  3. Метаданные передаются в виде пар имя-значение (данные публикации и параметры строки запроса).

После этого легко начать дискуссию об адаптациях, соглашениях о кодировании и передовых практиках.

Интересно, что в диссертации нет упоминаний об операциях HTTP POST, GET, DELETE или PUT. Это должно быть чье-то позднее толкование «лучшей практики» для «единого интерфейса».

Когда дело доходит до веб-сервисов, нам кажется, что нам нужен какой-то способ различения архитектур на основе WSDL и SOAP, которые добавляют значительные накладные расходы и, возможно, излишнюю сложность интерфейса. Они также требуют дополнительных структур и инструментов разработчика для реализации. Я не уверен, является ли REST лучшим термином для различия между интерфейсами здравого смысла и чрезмерно разработанными интерфейсами, такими как WSDL и SOAP. Но нам нужно что-то.

17
Nathan Andelin

Вот моя основная схема ОТДЫХА. Я попытался продемонстрировать мышление, лежащее в основе каждого из компонентов архитектуры RESTful, чтобы понимание концепции было более интуитивным. Надеюсь, это поможет демистифицировать REST для некоторых людей!

REST (Передача репрезентативного состояния) - это архитектура проекта, которая описывает, как сетевые ресурсы (то есть узлы, которые совместно используют информацию) проектируются и адресуются. В целом, архитектура RESTful делает так, чтобы клиент (запрашивающий компьютер) и сервер (отвечающий компьютер) могли запрашивать чтение, запись и обновление данных, при этом клиенту не нужно знать, как работает сервер и сервер может пройти назад без необходимости знать что-либо о клиенте. Хорошо, круто ... но как мы можем сделать это на практике?

  • Наиболее очевидным требованием является наличие какого-либо универсального языка, чтобы сервер мог сообщить клиенту, что он пытается сделать с запросом, и чтобы сервер ответил.

  • Но чтобы найти какой-либо конкретный ресурс, а затем сообщить клиенту, где он находится, необходим универсальный способ указания ресурсов. Это где универсальные идентификаторы ресурсов (URI) приходят; это в основном уникальные адреса для поиска ресурсов.

Но архитектура REST на этом не заканчивается! Хотя вышеперечисленное удовлетворяет основные потребности того, что нам нужно, мы также хотим иметь архитектуру, которая поддерживает большой объем трафика, поскольку любой данный сервер обычно обрабатывает ответы от ряда клиентов. Таким образом, мы не хотим перегружать сервер, заставляя его запоминать информацию о предыдущих запросах. 

  • Поэтому мы налагаем ограничение на то, что каждая пара запрос-ответ между клиентом и сервером является независимой, что означает, что серверу не нужно ничего запоминать о предыдущих запросах (предыдущих состояниях взаимодействия клиент-сервер), чтобы ответить на новый запрос. Это означает, что мы хотим, чтобы наши взаимодействия не имели состояния.

  • Чтобы еще больше облегчить нагрузку на наш сервер от повторения вычислений, которые недавно были выполнены для данного клиента, REST также позволяет кэширование. По сути, кэширование означает создание моментального снимка исходного ответа, предоставленного клиенту. Если клиент делает тот же запрос снова, сервер может предоставить клиенту моментальный снимок, а не повторять все вычисления, которые были необходимы для создания первоначального ответа. Однако, поскольку это моментальный снимок, если моментальный снимок не истек - сервер заранее устанавливает время истечения - и ответ был обновлен с момента первоначального кэша (т. Е. Запрос дал бы ответ, отличный от кэшированного ответа) клиент не увидит обновления до тех пор, пока не истечет срок действия кэша (или он не будет очищен) и ответ не будет обработан заново.

  • Последнее, что вы часто будете здесь о архитектурах RESTful, это то, что они являются многоуровневыми. На самом деле мы уже неявно обсуждали это требование в нашем обсуждении взаимодействия между клиентом и сервером. По сути, это означает, что каждый слой в нашей системе взаимодействует только с соседними слоями. Таким образом, в нашем обсуждении уровень клиента взаимодействует с уровнем нашего сервера (и наоборот), но могут быть и другие уровни сервера, которые помогают основному серверу обрабатывать запрос, с которым клиент не связывается напрямую. Скорее, сервер передает запрос по мере необходимости.

Теперь, если все это звучит знакомо, тогда замечательно. Протокол передачи гипертекста (HTTP), который определяет протокол связи через Всемирную паутину, является реализацией абстрактного понятия архитектуры RESTful (или экземпляра класса REST, если вы OOP фанатик как я). В этой реализации REST клиент и сервер взаимодействуют через GET, POST, PUT, DELETE и т.д., Которые являются частью универсального языка, и ресурсы можно указывать с помощью URL-адресов.

17
Kal

REST - это архитектурный паттерн и стиль написания распределенных приложений. Это не стиль программирования в узком смысле.

Сказать, что вы используете стиль REST, похоже на то, что вы построили дом в определенном стиле: например, в стиле Тюдоров или в викторианском стиле. И REST как стиль программного обеспечения, и Тюдор или викторианский стиль дома могут быть определены качествами и ограничениями, которые их составляют. Например, REST должен иметь разделение клиент-сервер, где сообщения с самоописанием. Дома в стиле Тюдор имеют перекрывающие фронтоны и крыши, которые имеют крутой наклон фронтонов. Вы можете прочитать диссертацию Роя, чтобы узнать больше об ограничениях и качествах, которые составляют ОТДЫХ.

REST, в отличие от домашних стилей, испытывал трудности с последовательным и практическим применением. Это могло быть преднамеренным. Оставляя его актуальную реализацию до дизайнера. Таким образом, вы можете делать то, что хотите, до тех пор, пока выполняете ограничения, изложенные в диссертации, которую вы создаете REST.

Бонус:

Вся сеть основана на REST (или REST была основана на сети). Поэтому, как веб-разработчик, вы можете знать об этом, хотя писать хорошие веб-приложения не обязательно. 

17
suing

Я думаю, что смысл restful - это разделение состояния на более высокий уровень при использовании Интернета (протокола) в качестве состояния без транспорта. Большинство других подходов перемешивают. 

Это был лучший практический подход, чтобы справиться с фундаментальными изменениями программирования в эпоху Интернета. Относительно фундаментальных изменений, у Эрика Мейера есть обсуждение на шоу здесь: http://www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity#view_93197 . Он резюмирует это как пять эффектов и представляет решение, разрабатывая решение на языке программирования. Решение также может быть достигнуто на уровне платформы или системы, независимо от языка. Отдых может рассматриваться как одно из решений, которое было очень успешным в современной практике. 

С спокойным стилем вы получаете и управляете состоянием приложения через ненадежный интернет. Если текущая операция не может получить правильное и текущее состояние, ей нужен принцип нулевой проверки, чтобы приложение могло продолжить работу. Если он не может манипулировать состоянием, он обычно использует несколько этапов подтверждения, чтобы все было правильно. В этом смысле отдых сам по себе не является целым решением, ему нужны функции в другой части стека веб-приложений для поддержки его работы. 

Учитывая эту точку зрения, стиль отдыха на самом деле не привязан к интернету или веб-приложению. Это фундаментальное решение многих ситуаций программирования. Это также не просто, это просто делает интерфейс действительно простым и удивительно хорошо справляется с другими технологиями. 

Просто мой 2с. 

Правка: два более важных аспекта: 

15
minghua

Это удивительно долгая «дискуссия» и все же довольно запутанная, если не сказать больше.

IMO:

1) Нет такой вещи, как спокойное программирование, без большого сустава и большого количества пива :)

2) Передача репрезентативного состояния (REST) ​​- это архитектурный стиль, указанный в диссертация Роя Филдинга . Он имеет ряд ограничений. Если ваш Сервис/Клиент уважает их, тогда это RESTful. Это оно. 

Вы можете суммировать (значительно) ограничения на:

  • связь без гражданства
  • соблюдайте спецификации HTTP (если используется HTTP)
  • четко передает передаваемые форматы контента
  • использовать гипермедиа как движок состояния приложения

Есть еще один очень хороший пост который хорошо объясняет вещи.

Многие ответы копируют/вставляют достоверную информацию, смешивая ее и добавляя некоторую путаницу. Люди говорят здесь об уровнях, об RESTFul URI (нет такого!), Применяют методы HTTP GET, POST, PUT ... REST не об этом или не только об этом.

Например, ссылки - это приятно иметь красивый API, но в конце концов клиент/сервер не заботится о ссылках, которые вы получаете/отправляете, это контент, который имеет значение. 

В конце концов любой клиент RESTful должен иметь возможность использовать любой сервис RESTful, если известен формат контента.

14
djodjo

REST === HTTP-аналог не верен до тех пор, пока вы не подчеркнете, что он "ДОЛЖЕН" быть HATEOAS

Рой сам очистил это здесь .

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

[Ошибка здесь подразумевает, что внешняя информация является движущей силой взаимодействия, а не гипертекста.]

11
lokesh

Старый вопрос, новый способ ответа. Есть много заблуждений об этой концепции. Я всегда стараюсь запомнить:

  1. Структурированные URL-адреса и методы/глаголы Http не являются определением Restful программирования. 
  2. JSON - это не спокойное программирование
  3. RESTful программирование не для API

Я определяю спокойное программирование как 

Приложение успокаивается, если оно предоставляет ресурсы (являющиеся комбинацией элементов управления данными и переходами между состояниями) в типе носителя, который понимает клиент

Чтобы быть спокойным программистом, вы должны пытаться создавать приложения, которые позволяют актерам делать что-то. Не только разоблачение базы данных.

Элементы управления переходом между состояниями имеют смысл только в том случае, если клиент и сервер договариваются о представлении медиа-типа ресурса. В противном случае нет способа узнать, что такое элемент управления, а что нет, и как выполнить элемент управления. IE, если браузеры не знают тегов <form> в html, вам нечего будет отправлять в переходное состояние в вашем браузере. 

Я не стремлюсь к саморекламе, но я подробно расскажу об этих идеях в своем выступлении http://techblog.bodybuilding.com/2016/01/video-what-is-restful-200.html ,.

Выдержка из моего выступления о часто упоминаемой модели зрелости Ричардсона, я не верю в уровни, вы либо RESTful (уровень 3), либо нет, но то, что я хотел бы сказать об этом, это то, что каждый уровень делает для вас на пути к RESTful

 annotated richardson maturity model

11
Chris DaMour

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 обновляет существующий ресурс или создает новый ресурс.
11
Imran

REST определяет 6 архитектурных ограничений, которые делают любой веб-сервис - true RESTful API.

  1. Единый интерфейс 
  2. Клиент-сервер 
  3. Stateless 
  4. Cacheable 
  5. Многоуровневая система
  6. Код по запросу (необязательно)

https://restfulapi.net/rest-architectural-constraints/

10
Jaider

Talking - это больше, чем просто обмен информацией. Протокол на самом деле разработан таким образом, чтобы не было разговоров. Каждая сторона знает, какова их конкретная работа, потому что это указано в протоколе. Протоколы позволяют осуществлять чистый обмен информацией за счет каких-либо изменений в возможных действиях. Разговор, с другой стороны, позволяет одной стороне спросить, какие дальнейшие действия могут быть предприняты другой стороной. Они могут даже задать один и тот же вопрос дважды и получить два разных ответа, поскольку за это время состояние другой стороны могло измениться. Говорят это архитектура RESTful . Тезис Филдинга определяет архитектуру, которой нужно было бы следовать, если бы вы хотели, чтобы машины говорили друг с другом, а не просто общались.

10
qmckinsey

REST обозначает Передача репрезентативного состояния.

Он основывается на протоколе обмена данными между клиентом и сервером, не зависящем от состояния, и практически во всех случаях используется протокол HTTP.

REST часто используется в мобильных приложениях, веб-сайтах социальных сетей, инструментах гибридов и автоматизированных бизнес-процессах. Стиль REST подчеркивает, что взаимодействие между клиентами и сервисами улучшается благодаря ограниченному количеству операций (глаголов). Гибкость обеспечивается назначением ресурсов (существительных) их собственных уникальных универсальных индикаторов ресурсов (URI). 

Введение об отдыхе

10
GowriShankar

Само по себе понятия «программирование RESTful» не существует. Лучше было бы назвать парадигму RESTful или даже лучше архитектуру RESTful. Это не язык программирования. Это парадигма.

Из Википедии :

В вычислениях передача состояния представления (REST) ​​является архитектурный стиль, используемый для веб-разработки.

10
ACV

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

При правильно реализованной спокойной операции GET не должно иметь значения, поступает ли информация из БД вашего сервера, из кэша вашего сервера, CDN, кэша прокси-сервера, кэша вашего браузера или локального хранилища вашего браузера. Можно использовать самый быстрый, самый доступный на сегодняшний день источник.

Утверждение, что Rest - это всего лишь синтаксическое изменение от использования запросов GET с параметром action к использованию доступных http-глаголов, делает его похожим на бесполезный и чисто косметический. Суть в том, чтобы использовать язык, который может быть понят и оптимизирован каждой частью цепочки. Если ваша операция GET имеет действие с побочными эффектами, вам придется пропустить все HTTP-кэширование, иначе вы получите противоречивые результаты.

9
Benoit Essiambre

Это очень редко упоминается повсюду, но модель зрелости Richardson - один из лучших способов на самом деле судить, насколько Restful является чьим-то API. Подробнее об этом здесь:

Модель зрелости Ричардсона

5
kg11

Что такое Тестирование API ?

Тестирование API использует программирование для отправки вызовов API и получения дохода. Тестирование рассматривает тестируемый сегмент как черный ящик. Цель тестирования API - подтвердить правильность выполнения и грубую обработку части, предшествующей ее согласованию в приложении.

REST API

ОТДЫХ: Представительский государственный трансферт. 

  • Это набор функций, по которым тестировщики выполняют запросы и получают ответы. В REST API взаимодействия осуществляются по протоколу HTTP. 
  • REST также разрешает связь между компьютерами по сети. 
  • Для отправки и получения сообщений он использует методы HTTP и не требует строгого определения сообщения, в отличие от веб-служб. 
  • Сообщения REST часто принимают форму в форме XML или JavaScript Object Notation (JSON). 

4 Часто используемые методы API: - 

  1. GET: - Предоставляет доступ только для чтения к ресурсу.
  2. POST: - Он используется для создания или обновления нового ресурса.
  3. PUT: - используется для обновления или замены существующего ресурса или создания нового ресурса. 
  4. УДАЛИТЬ: - Используется для удаления ресурса.

Шаги для тестирования API вручную: -

Чтобы использовать API вручную, мы можем использовать браузерные плагины REST API. 

  1. Установите плагин POSTMAN (Chrome)/REST (Firefox)
  2. Введите URL API
  3. Выберите метод REST
  4. Выберите заголовок контента
  5. Введите запрос JSON (POST)
  6. Нажмите на отправить
  7. Он вернет ответ

Шаги по автоматизации REST API

5
kkashyap1707

Я бы сказал, что важный строительный блок в понимании REST лежит в конечных точках или отображениях, таких как /customers/{id}/balance.

Вы можете представить себе такую ​​конечную точку, как соединительный конвейер от веб-сайта (внешний интерфейс) к вашей базе данных/серверу (внутренний). Используя их, клиентский интерфейс может выполнять серверные операции, которые определены в соответствующих методах любого сопоставления REST в вашем приложении.

1
Kürsat Aydinli

Эти ответы, содержащие примеры связанных ресурсов, - это здорово, но это только половина картины.

Итак, представьте, что вы разрабатываете сайт. Ты пишешь историю,

Я хочу иметь возможность искать адрес по почтовому индексу, чтобы я мог выбрать адрес доставки

Затем вы создадите сайт, чтобы принять пользователя в этом путешествии, и попытаться связать страницы вместе в рабочем процессе.

Дизайн веб-сайта, который перенес их на поиск адреса, а затем оставил их, чтобы скопировать адрес в буфер обмена и затем вернуться к форме адреса доставки, был бы не очень полезным.

REST API использует шаблоны, которые мы воспринимаем как само собой разумеющееся в Интернете, для взаимодействия машина-машина.

Функция поиска по почтовому индексу не должна быть base/addresses/{postcode}, и коллекция возвращается, даже если каждый адрес ссылается на полный адрес и некоторые ссылки для редактирования, потому что это тупик; потребитель API должен будет угадать, как использовать адрес.

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

1 GET /orders/123/shipping

  200 OK { Current shipping details + link to parent + link to address picker }

2  -> GET /orders/123/shipping/addresspicker

      200 OK { Link and form for searching for a postcode }

3   -> GET /orders/123/shipping/addresspicker?postcode=tn11tl

       200 OK { List of addresses each with link to pick it }

4    -> POST /orders/123/shipping/addresspicker?postcode=tn11tl&pickNo=3

        200 OK { Current shipping details + link to parent + link to address picker }

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

HTTP-запрос/ответ не является строго частью REST, но я не думаю, что кто-либо когда-либо видел не-HTTP REST приложение.

Теперь эти URL могут быть любым набором символов, они просто идентификаторы, я сделал их красивыми, потому что они имеют смысл для людей. Машина будет использовать rel для определения того, что они делают, не завися от читаемой href.

0
Luke Puplett