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


3984

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


3
см. также ответ по следующей ссылке stackoverflow.com/a/37683965/3762855
Ciro Corvino


1
Кроме того, перейдите по
Ashraf.Shk786


5
@ OLIVER.KOO приятное наблюдение. Просто я спросил это в то время, когда это было что-то новое. Это было разбросано вокруг много, но не многие люди знали, что это было. По крайней мере, я этого не сделал, и, похоже, мой вопрос об этом помог им, потому что они тоже хотели знать.
hasen

Ответы:


743

Архитектурный стиль называется 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 книги Дэвида М. Гири.


2
Перечень доступных операций Идемпотент: GET (Безопасный), PUT & DELETE (Исключение упоминается в этой ссылке restapitutorial.com/lessons/idempotency.html). Дополнительный справочник по безопасной и идемпотентной Методе w3.org/Protocols/rfc2616/rfc2616-sec9.html
Abhijeet

5
а) важным моментом в GET является безопасность, а не идемпотентность, б) @Abhijeet: RFC 2616 был отменен в 2014 году; см. RF 7230ff.
Джулиан Решке

12
Это не верно. Прочитайте это для правильной интерпретации REST roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven или этого stackoverflow.com/questions/19843480/...
kushalvm

4
@kushalvm Это академическое определение REST не используется на практике.
Воинственный шимпанзе

3
По сути, мы можем задаться вопросом, является ли концепция работоспособной, поскольку мы не можем просто дать ей устойчивое и понятное определение для всех
HoCo_

2918

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 обычно применялся несколько лет назад, когда я сначала написал это, а не его истинное значение. Я пересмотрел ответ, чтобы лучше представить реальное значение.)


178
Нет. REST не просто всплыл как еще одно модное слово. Он возник как средство описания альтернативы обмену данными на основе SOAP. Термин REST помогает сформировать обсуждение о том, как передавать и получать доступ к данным.
tvanfosson

111
Тем не менее, суть REST (в практическом применении) - «не используйте GET для внесения изменений, используйте POST / PUT / DELETE», и это совет, который я слышал (и следую) еще задолго до появления SOAP. REST уже всегда был там, он просто не получил название за «путь, чтобы сделать это» до недавнего времени .
Дейв Шерохман

37
Не забудьте "Гипертекст как двигатель состояния приложения".
Хэнк Гей

45
Этот ответ не соответствует сути. HTTP едва упоминается в диссертации Филдинга.
user359996

18
В этом ответе не упоминается цель REST, и кажется, что все дело в чистых URI. Хотя это может быть популярным восприятием REST, ответы D.Shawley и oluies более точны - речь идет о возможности использовать преимущества встроенных в архитектуру функций, таких как кеширование, работая с ним, а не против него. Более симпатичные URI являются в основном распространенным побочным эффектом.
TR

534

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 заключается в том, чтобы не зацикливаться на деталях технологии и реализации. Сконцентрируйтесь на том, кому принадлежат ресурсы, кто отвечает за их создание / обслуживание и т. Д. Затем подумайте о представлениях, протоколах и технологиях.


36
Ответ, обеспечивающий список чтения, очень подходит для этого вопроса.
ellisbben

25
Спасибо за обновления. PUTи на POSTсамом деле не сопоставлять один на один с обновлением и созданием. PUTможет использоваться для создания, если клиент диктует, какой будет URI. POSTсоздается, если сервер назначает новый URI.
Д.Шоули

8
Не забывайте патч.
эпитка

4
URN - это URI, который использует urn:схему. Концептуально нет никакой разницы; тем не менее, URN требует, чтобы у вас был отдельный метод для определения местоположения ресурса, идентифицированного (названного) URN. Необходимо позаботиться о том, чтобы вы не вводили неявную связь при сопоставлении именованных ресурсов и их расположения.
Д.Шоули

2
@ellisbben Согласен. Если я правильно понимаю, это диссертация, которая привела к REST: ics.uci.edu/~fielding/pubs/dis Диссертация/rest_arch_style.htm
Филип Коулинг

408

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

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

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

39
Для меня этот ответ уловил суть желаемого ответа. Просто и прагматично. Конечно, есть много других критериев, но приведенный пример - отличная стартовая площадка.
CyberFonic

92
В последнем примере @pbreitenbach использует PUT fname=Jonny. Это установило бы lnameи ageзначения по умолчанию (возможно, NULL или пустую строку и целое число 0), потому что a PUT перезаписывает весь ресурс данными из предоставленного представления. Это не то, что подразумевается под «обновлением», чтобы сделать реальное обновление, используйте PATCHметод, поскольку это не изменяет поля, которые не указаны в представлении.
Николас Шенкс

24
Николай прав. Кроме того, URI для первого POST, создающего пользователя, должен называться users, поскольку он /user/1не имеет смысла и должен быть в списке /users. Ответ должен быть 201 Createdа не просто ОК в этом случае.
DanMan

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

Это очень компактный ответ, который охватывает все методы доступа к сервлету http
Himanshu Ahuja

181

Отличная книга о ОТДЫХЕ - ОТДЫХ на практике .

Должны быть чтения Передача состояния представления (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 и управление версиями обсуждают расширяемость, управление версиями, эволюционируемость и т. Д. Через модифицируемость


5
Я думаю, что этот ответ касается ключевой точки понимания REST: что означает слово репрезентация . Уровень 1 - Ресурсы говорят о состоянии . Уровень 2 - HTTP-глаголы говорят о передаче (читай изменение ). Уровень 3 - HATEOAS говорит, что управляет будущими передачами через представление (возвращается JSON / XML / HTML), что означает, что вы уже знаете, как сказать следующий раунд разговора с возвращенной информацией Таким образом, REST гласит: «(представление (передача состояния))» вместо «((представление состояния) передача)».
LCN


136

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

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 называется безгражданством?
Chaklader Asfak Arefe

89

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

18
Это «правильно использует HTTP», что не то же самое, что «успокоительный» (хотя это связано с ним)
Джулиан Решке

2
Вы также можете использовать / user / del / 2 и / user / remove / 2 или ... GET / DELETE / PUT / POST - это просто стандартизированный, «правильный» способ делать такие вещи (и, как говорит Джулиан, это еще не все есть ОТДЫХ)
дбр

1
Конечно, но это не повод избегать их ... REST просто спасает вас от необходимости заново изобретать колесо. Для API REST хорош (непротиворечивость!), Но для структурирования случайного веб-сайта это не имеет значения, я бы сказал (это может быть более хлопотно, чем стоит)
dbr

14
Вадим, это был бы просто RPC. Также опасно использовать GET для изменения данных, поскольку (среди прочих причин) поисковая система может подсмотреть ваши ссылки для удаления и посетить их все.
aehlke

7
@aehlke - я думаю, что реальный вопрос будет таким: «Почему анонимный пользователь имеет возможность удалять записи из вашей системы?»
Спенсер Рупорт

68

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

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


2
но не прямолинейно .. делает это более сложным, чем должно быть.
hasen

4
Кроме того, хотя термины REST и RESTful сейчас используются почти исключительно в области веб-приложений, технически ничто не связывает REST с HTTP.
Хэнк Гей

3
В блоге Филдинга есть несколько хороших, более простых для понимания статей о REST и распространенных заблуждениях: roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
aehlke

3
@HankGay Я думаю, причина этого не в том, что большинство разработчиков веб-сервисов рассматривают REST как замечательное упрощение по сравнению с альтернативами, такими как SOAP. Они не обязательно придерживаются правильности всех технических приемов REST - и это, вероятно, сводит с ума фанатиков REST - но в большинстве случаев им, вероятно, не нужно беспокоиться о таких вещах, как уверенность в том, что их результаты «гипермедиа-включены».
настроение

47

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

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

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

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

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

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

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


Эта статья объясняет взаимосвязь между HTTP и REST freecodecamp.org/news/...
Only You

45

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

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

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


12
классные ссылки, спасибо. Я устал от тех ребят из REST, которые говорят, что какой-то пример не «REST-фул», но потом отказываются говорить, как изменить пример, чтобы он был «REST-фул».
coder_tim

38

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

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

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

1
Что Communication is Done by Representationзначит?
mendez7

33

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

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

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


7
так .... как этот пример будет успокоительным? Как бы вы изменили URL, чтобы сделать его спокойным?
hasen

1
hasen: использование одного ресурса для всех операций может быть необходимо для RESTfulness, но этого недостаточно .
Кен

18
хорошо хорошо .. не могли бы вы объяснить дальше? Какой смысл говорить "нет, эти парни не правы ... Я знаю, что правильно", не говоря, что вы знаете (или думаете), чтобы быть правым?
hasen

5
Я дал ссылку на описание Филдинга. Я думал, что сказал точно соответствующий diff другим ответам: должен управляться гипертекстом. Если "/ user / 123" взято из какой-то внешней документации по API, то это не RESTful. Если это происходит из идентификатора ресурса в вашем гипертексте, то это так.
Кен

1
Или вы можете использовать точку входа, например / users /, и она предоставит вам список пользовательских ресурсов и URI для каждого. Тогда ресурсы обнаруживаются, а навигация - на основе гипертекста.
aehlke

26

Ответ очень прост, есть диссертация, написанная Роем Филдингом.] 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 году мы были в конечном итоге уничтожены Скайнетом. До тех пор ... ;-)


22

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

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

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

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


17

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

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

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

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

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


17

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

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

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

Бонус:

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


17

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

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

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

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

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

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

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

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

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


15

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

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

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

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

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

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


1
Точка зрения MVC : блог Rest Worst Practices предлагает не смешивать модели и ресурсы . Книга Two Scoops of django предполагает, что Rest API - это представление, а не смешивание бизнес-логики с представлением. Код для приложения должен оставаться в приложении.
Минхуа


14

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

IMO:

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

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

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

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

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

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

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

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


14

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

  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

Аннотированная модель зрелости Ричардсона


12

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

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

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


Филдинг добавил некоторые дополнительные правила, которых должны придерживаться RESTful API / клиенты
Роман Воттнер,

11

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

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

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

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


не отвечает на вопрос так же хорошо, как другие, но +1 за информацию, которая имеет отношение!
CybeX

Я думаю, что это тоже отвечает на вопрос, но, например, в нем отсутствует безгражданство. Каждое ограничение важно ... Стандартная часть типа носителя не всегда верна. Я имею в виду, что есть слои понимания. Например, если вы используете RDF, то тип медиа можно понять, но смысл контента нет. Таким образом, клиент должен знать словарный запас. Некоторые люди экспериментируют с такого рода API REST и общим словарём REST для описания гиперссылок и т. Д. Hydra-cg.com
inf3rno

11

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

Несколько цитат, но ни один источник не упоминается. Где ты это взял?
djvg

10

REST расшифровывается как представительский государственный перевод .

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

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

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


10

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


10

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

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

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


9

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

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

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


5
«Сказать, что Отдых - это всего лишь синтаксическое изменение ... делает его похожим на то, что оно не приносит никакой пользы и является чисто косметическим» - именно поэтому я читаю здесь ответы на SO. Обратите внимание, что вы не объяснили, почему REST не является чисто косметическим.
OSA

5

Что такое 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
это даже не правильный ответ
есть

5

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

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


Если вы посмотрите на ограничения, накладываемые Fielding на REST, вы ясно увидите, что API должен достигнуть 3-го уровня RMM, чтобы его можно было рассматривать как RESTful, хотя на самом деле этого недостаточно, поскольку все еще достаточно возможностей для сбоя. Идея REST - отделение клиентов от серверных API. Конечно, уровень 3 удовлетворяет ограничению HATEOAS, но все еще легко нарушить требования и жестко
связать

2

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.