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




rest расшифровка (20)

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

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


Что такое REST?

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

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

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

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

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

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

http://rest.elkstein.org/


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

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

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

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

roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven После этого термин RESTful также был исчерпан. В настоящее время мы говорим о API-интерфейсах веб-интерфейсов и API-интерфейсах Hypermedia , поскольку большинство так называемых приложений REST не соответствовали части HATEOAS равномерного ограничения интерфейса.

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

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

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

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

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

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

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

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

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

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

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

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


Программирование 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 ( RFC3040 и RFC3040 в частности) и рассмотрите, как и почему кеширование работает так, как оно делает. В конце концов, он просто щелкнет. Последнее откровение для меня было, когда я увидел сходство между DNS и HTTP. После этого становится понятно, почему масштабируемые интерфейсы SOA и Message Passing Interfaces становятся доступными.

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


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

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

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

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

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

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

Этот документ xfront объясняет разницу между REST и SOAP, и это тоже очень полезно. Когда Филдинг говорит: « roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven ». Ясно, что RPC не является RESTful, поэтому полезно увидеть точные причины этого. (SOAP - это тип RPC.)


Это программирование, где архитектура вашей системы соответствует ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm изложенному Роем Филдингом в его диссертации . Поскольку это архитектурный стиль, который описывает веб (более или менее), в нем заинтересованы многие люди.

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


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

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

http://rest.elkstein.org/

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

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

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

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


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

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

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

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


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

API, который придерживается принципов REST , не требует от клиента ничего знать о структуре API. Скорее, сервер должен предоставлять любую информацию, которую клиент должен взаимодействовать с сервисом. Примером этого может служить HTML-форма : Сервер определяет местоположение ресурса и требуемые поля. Браузер не знает заранее, куда подавать информацию, и заранее не знает, какую информацию отправить. Обе формы информации полностью предоставляются сервером. (Этот принцип называется HATEOAS : Hypermedia как двигатель состояния приложения .)

Итак, как это относится к HTTP и как его можно реализовать на практике? HTTP ориентирован на глаголы и ресурсы. Два глагола в основном использовании GET и POST, которые, как я думаю, все узнают. Тем не менее, стандарт HTTP определяет несколько других, таких как PUT и DELETE. Эти глаголы затем применяются к ресурсам в соответствии с инструкциями, предоставленными сервером.

Например, представим себе, что у нас есть пользовательская база данных, управляемая веб-службой. В нашей службе используется настраиваемая гипермедиа на основе JSON, для которой мы назначаем приложение mimetype / json + userdb (может быть также приложение / xml + userdb и application / whatever + userdb - многие типы носителей могут поддерживаться). Клиент и сервер были запрограммированы так, чтобы понимать этот формат, но они ничего не знают друг о друге. Как указывает roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven :

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"
        }
    ]
}

Из описания наших СМИ мы знаем, что мы можем найти информацию о связанных ресурсах из разделов, называемых «ссылками». Это называется элементами управления Hypermedia . В этом случае мы можем сказать из такого раздела, что мы можем найти список пользователей, выполнив другой запрос для /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"
        }
    ]
}

Мы можем многое сказать из этого ответа. Например, теперь мы знаем, что мы можем создать нового пользователя с помощью POSTing to /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 означает передачу состояния представления .

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

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

Введение в Отдых


Архитектурный стиль, называемый REST (State State State Transfer), защищает веб-приложения от использования HTTP, как это первоначально предполагалось . Поиск должен использовать запросы GET . GET должны использоваться для мутации, создания и удаления соответственно .

Сторонники 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 должны быть idempotent . То есть, выдача запроса дважды не должна отличаться от его выдачи один раз. Это делает запросы кэшируемыми. Запрос «добавить в корзину» не является идемпотентным - выпуск его дважды добавляет две копии товара в корзину. В этом контексте явно подходит запрос POST. Таким образом, даже веб-приложение RESTful нуждается в своей части запросов POST.

Это взято из превосходной книги Core JavaServer, стоящей перед книгой Дэвида М. Гири.


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

REST описывает сетевую систему, состоящую из трех частей:

  1. элементы данных (ресурс, идентификатор ресурса, представление)
  2. разъемы (клиент, сервер, кеш, резольвер, туннель)
  3. компоненты (исходный сервер, шлюз, прокси, пользовательский агент)

REST строго соответствует следующим условиям:

  1. Статус функциональности приложения разделяется на ресурсы
  2. Каждый ресурс, используемый в качестве синтаксиса позиционирования гиперссылок (т. Е. В URI WWW)
  3. Все ресурсы имеют единый интерфейс между клиентом и состоянием перехода ресурса, в том числе:
    1. Ограниченный набор четко определенных операций (т. Е. В HTTP GET / POST / PUT / DELETE)
    2. Ограниченный набор типов содержимого форматов контента, который может включать исполняемый код (т. Е. В WWW Javascript)

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

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

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

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

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


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

IMO:

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

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

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

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

Есть еще одна roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven которая прекрасно объясняет ситуацию.

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

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

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


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

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

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

Бонус:

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


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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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





definition