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

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

Архитектурный стиль называется REST (Representational State Transfer) выступает , что веб - приложения должны использовать 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/whatever+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"
        }
    ]
}

Мы можем многое сказать из этого ответа. Например, теперь мы знаем, что можем создать нового пользователя, 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 для веб-фреймворков - это аналогичный тест на зрелость для веб-фреймворков.

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

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

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

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

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

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

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

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

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

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

http://rest.elkstein.org/

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

Вместо того, чтобы использовать определенный URL для удаления метода (скажем, /user/123/delete), вы бы отправили запрос 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 доктора М. Элькштейна и процитировал основную часть, которая ответила бы на ваш вопрос по большей части:

Learn REST: учебное пособие

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

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

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

Я не думаю, что вы должны чувствовать себя глупо, если не слышите о REST вне переполнения стека ..., я бы попал в ту же ситуацию !; ответы на этот другой SO вопрос о том, почему 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-ограничения следующие:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Бонус:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Изменить: еще два важных аспекта:

• Безгражданство вводит в заблуждение. Речь идет об остальном API, а не о приложении или системе. Система должна быть с состоянием. Restful design - это проектирование системы с сохранением состояния на основе API без сохранения состояния. Некоторые цитаты из другого QA :

  • REST работает с представлениями ресурсов, каждое из которых идентифицируется URL-адресом. Обычно это не объекты данных, а абстракции сложных объектов .
  • REST расшифровывается как «передача состояния репрезентации», что означает, что речь идет о передаче и изменении состояния некоторого ресурса в системе.

• Идемпотентность : часто пропускаемая часть REST - идемпотентность большинства глаголов. Это приводит к надежным системам и меньшей взаимозависимости точных интерпретаций семантики .

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

IMO:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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: -

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

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

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

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

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