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

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

Ответ 1

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

Ответ 2

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 моей жене.
Мысли Мартина Фаулера
PayPal API имеет элементы управления гипермедиа

(Этот ответ был предметом большого количества критики за то, что упустил из виду. По большей части это была справедливая критика. То, что я первоначально описал, больше соответствовало тому, как REST обычно применялся несколько лет назад, когда я сначала написал это, а не его истинное значение. Я пересмотрел ответ, чтобы лучше представить реальное значение.)

Ответ 3

Программирование RESTful:

ресурсы идентифицируются постоянным идентификатором: URI являются вездесущим выбором идентификатора в наши дни Ресурсы
управляются с помощью общего набора глаголов: 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 Interfaces масштабируются, начинает щелкнуть.

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

Ответ 4

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

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

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

Ответ 5

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

Должны читать Репрезентативный перевод состояния (REST) и REST API должны с гипертекстом

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

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

Ограничение HATEOAS - это аббревиатура для Hypermedia как двигателя Состояние приложения. Этот принцип ключевой дифференциал между REST и большинство других форм клиентского сервера система.

...

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

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

Приближение чистого REST: Обучение любимому HATEOAS - хорошая коллекция ссылок.

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

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

Ответ 6

Что такое REST?

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

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

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

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

Несмотря на простоту, REST является полнофункциональным; там в основном вы ничего не можете сделать в веб-службах, которые не могут быть выполнены с помощью RESTful архитектура. REST не является "стандартным". Никогда не будет W3C рекомендация для REST, например. И хотя есть REST рамки программирования, работа с REST настолько проста, что вы можете часто "сворачивайтесь" со стандартными библиотечными функциями на таких языках, как Perl, Java или С#.

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

http://rest.elkstein.org/

Ответ 7

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

Вместо того, чтобы использовать конкретный URL-адрес для удаления метода (например, /user/123/delete), вы должны отправить запрос DELETE на URL /user/[id], чтобы отредактировать пользователя, чтобы получить информацию о пользователе, который вы отправляете запрос GET до /user/[id]

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

GET /delete_user.x?id=123
GET /user/delete
GET /new_user.x
GET /user/new
GET /user?id=1
GET /user/id/1

Вы используете HTTP-глаголы и имеете..

GET /user/2
DELETE /user/2
PUT /user

Ответ 8

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

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

Ответ 9

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

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

Объяснение REST и Hypertext: Спам-E робот для очистки спама

И еще лучше, здесь есть чистое объяснение с простыми примерами (PowerPoint более комплексный, но вы можете получить большую часть его в html-версии):

http://www.xfront.com/REST.ppt или http://www.xfront.com/REST.html

Прочитав примеры, я понял, почему Кен говорит, что REST управляется гипертекстом. Я на самом деле не уверен, что он прав, потому что этот/пользователь/123 - это URI, указывающий на ресурс, и мне не ясно, что он не разрешен только потому, что клиент знает об этом "вне диапазона".

Этот документ xfront объясняет разницу между REST и SOAP, и это тоже очень полезно. Когда Филдинг говорит: " Это RPC, он кричит RPC". Он ясно показывает, что RPC не RESTful, поэтому полезно увидеть точные причины этого. (SOAP - это тип RPC.)

Ответ 10

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

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

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

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

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

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

Ответ 11

Что такое REST?

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

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

Ответ 12

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

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

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

Ответ 13

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

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

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

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

Таким образом, он не работает, например, сокеты PUB/SUB, он основан на REQ/REP.
связь без гражданства

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

Поэтому вам не нужно снова и снова выполнять одни и те же запросы.
единый интерфейс как общий контракт между клиентом и сервером

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

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

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

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

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

Ответ 14

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

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

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

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

Ответ 15

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

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

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

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

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

Ответ 16

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

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

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

Bonus:

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

Ответ 17

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

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

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

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

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

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

Ответ 18

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

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

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

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

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

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

Безгражданство вводит в заблуждение. Речь идет об остальном API, а не о приложении или системе. Система должна быть работоспособной. Решительный дизайн - это проектирование системы с сохранением состояния, основанной на API без состояния. Некоторые цитаты из другого QA:
- REST, работает с представлениями ресурсов, каждый из которых идентифицируется URL-адресом. Обычно это не объекты данных, а сложные абстракции объектов.
- REST означает "репрезентативная передача состояния", что означает все это о передаче и изменении состояния какого-либо ресурса в системе.
Идемпотентность: часто игнорируемая часть REST - это идемпотентность большинства глаголов. Это приводит к созданию надежных систем и меньшей взаимозависимости точных интерпретаций семантики.

Ответ 19

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

REST получила широкое признание в Интернете [цитата] как более простая альтернатива веб-сервисам на основе SOAP и WSDL. Системы RESTful обычно, но не всегда, обмениваются данными по протоколу передачи гипертекста с теми же HTTP-глаголами (GET, POST, PUT, DELETE и т.д.), Которые используются веб-браузерами для извлечения веб-страниц и отправки данных на удаленные серверы.

Архитектурный стиль REST был разработан группой технической архитектуры W3C (TAG) параллельно с HTTP 1.1 на основе существующего проекта HTTP 1.0. Всемирная паутина представляет собой самую большую реализацию системы, соответствующей архитектурному стилю REST.

Архитектурные ограничения

Архитектурные свойства REST реализуются путем применения конкретных ограничений взаимодействия к компонентам, соединителям и элементам данных. Официальные ограничения REST:

клиент-сервер

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

Stateless

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

Cacheable

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

Многоуровневая система

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

Код по требованию (необязательно)

Серверы могут временно расширять или настраивать функциональные возможности клиента путем передачи исполняемого кода. Примерами этого могут быть скомпилированные компоненты, такие как Java-апплеты и клиентские скрипты, такие как JavaScript. "Код по требованию" является единственным необязательным ограничением архитектуры REST.

Равномерный интерфейс

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

Ответ 20

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

ММО:

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

2) Репрезентативный перенос состояний (REST) - это архитектурный стиль, указанный в очень хороший пост, который прекрасно объясняет ситуацию.

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

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

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

Ответ 21

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

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

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

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

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

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

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

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

Ответ 22

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

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

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

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

Ответ 23

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

Ответ 24

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

Равномерный интерфейс
Клиент-сервер
Stateless
Cacheable
Многослойная система
Код по запросу (необязательно)

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

Ответ 25

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

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

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

Введение в Rest

Ответ 26

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

Ответ 27

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

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

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

Ответ 28

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

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

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

Ответ 29

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

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

API REST

ОТДЫХ: Передача репрезентативного состояния.

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

4 Используемые методы API:

GET: - предоставляет доступ только к ресурсу только для чтения.
POST: - Используется для создания или обновления нового ресурса.
PUT: - Используется для обновления или замены существующего ресурса или создания нового ресурса.
DELETE: - используется для удаления ресурса.

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

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

Установите плагин POSTMAN (Chrome)/REST (Firefox)
Введите URL-адрес API
Выберите метод REST
Выберите контент-заголовок
Введите запрос JSON (POST)
Нажмите, чтобы отправить
Он вернет выходной отклик

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

Ответ 30

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

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