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

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

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

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

например, представим, что у нас есть база данных пользователей, управляемая веб-службой. Наш сервис использует пользовательскую гипермедиа на основе JSON, для которой мы назначаем mimetype application / json+userdb (также может быть application / xml+userdb и применение / что угодно + userdb - многие типы носителей могут быть поддерживаемый.) Клиент и сервер были запрограммированы на понимание этого формата, но они ничего не знают друг о друге. As Рой Филдинг отмечает:

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

запрос на базовый ресурс / может возвращать что-то вроде этого:

запрос

GET /
Accept: application/json+userdb

ответ

200 OK
Content-Type: application/json+userdb

{
    "version": "1.0",
    "links": [
        {
            "href": "/user",
            "rel": "list",
            "method": "GET"
        },
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

мы знаем из описания наших медиа, что мы можем найти информацию о связанных ресурсах из разделов, называемых "ссылки". Это называется управление гипермедиа. В этом случае мы можем сказать из такого раздела, что мы можем найти список пользователей по еще один запрос на /user:

запрос

GET /user
Accept: application/json+userdb

ответ

200 OK
Content-Type: application/json+userdb

{
    "users": [
        {
            "id": 1,
            "name": "Emil",
            "country: "Sweden",
            "links": [
                {
                    "href": "/user/1",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/1",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/1",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        },
        {
            "id": 2,
            "name": "Adam",
            "country: "Scotland",
            "links": [
                {
                    "href": "/user/2",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/2",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/2",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        }
    ],
    "links": [
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

мы можем многое сказать из этого ответа. Например, теперь мы знаем, что можем создать нового пользователя, разместив его в /user:

запрос

POST /user
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Karl",
    "country": "Austria"
}

ответ

201 Created
Content-Type: application/json+userdb

{
    "user": {
        "id": 3,
        "name": "Karl",
        "country": "Austria",
        "links": [
            {
                "href": "/user/3",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/3",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/3",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

мы также знаем, что мы можем изменить существующую данные:

запрос

PUT /user/1
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Emil",
    "country": "Bhutan"
}

ответ

200 OK
Content-Type: application/json+userdb

{
    "user": {
        "id": 1,
        "name": "Emil",
        "country": "Bhutan",
        "links": [
            {
                "href": "/user/1",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/1",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/1",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

обратите внимание, что мы используем разные http-глаголы (GET, PUT, POST, DELETE и т. д.) манипулировать этими ресурсами, и что единственное знание, которое мы предполагаем со стороны клиентов, - это наше определение СМИ.

читайте далее:

• многие гораздо лучшие ответы на этой странице.
• как я объяснил Покойся с миром, моя жена!--29-->.
• как я объяснил отдых моей жене.
• Мартин Фаулер мысли!--29-->
• API Paypal имеет элементы управления гипермедиа

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

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

• ресурсы, идентифицируемые постоянным идентификатором: URI являются вездесущим выбором идентификатора в эти дни
• ресурсы манипулируются с помощью общего набора глаголов: HTTP-методы-это часто встречающийся случай-почтенный Create, Retrieve, Update, Delete становится POST, GET, PUT и DELETE. Но REST не ограничивается HTTP, это просто наиболее часто используемый транспорт прямо сейчас.
• фактическое представление, полученное для ресурса, зависит от запроса, а не от идентификатора: используйте заголовки Accept для управления тем, хотите ли вы XML, HTTP или даже объект Java, представляющий ресурс
• поддержание состояния в объекте и представление состояния в представлении
• представление отношений между ресурсами в представлении ресурса: связи между объектами внедряются непосредственно в представление
• представления ресурсов описывают, как представление может быть использовано и при каких обстоятельствах оно должно быть отброшено/повторно установлено согласованным образом: использование заголовков HTTP Cache-Control

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

если вас действительно интересует, что такое архитектура RESTful и почему она работает, прочитайте диссертацию несколько раз и прочитала целиком не только Глава 5! Следующий взгляд в почему работает DNS. Читайте об иерархической организации DNS и как рефералы работа. Затем прочитайте и рассмотрите, как работает кэширование DNS. Наконец, прочитайте спецификации HTTP (адресу rfc2616 и RFC3040 в частности) и рассмотрим, как и почему кэширование работает так, как оно работает. В конце концов, он просто щелкнет. Последнее откровение для меня было, когда я увидел сходство между DNS и HTTP. После этого понимание того, почему SOA и интерфейсы передачи сообщений масштабируемы, начинает щелкать.

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

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

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

POST /user
fname=John&lname=Doe&age=25

сервер отвечает:

200 OK
Location: /user/123

в будущем, вы можете получить сведения о пользователе:

GET /user/123

сервер отвечает:

200 OK
<fname>John</fname><lname>Doe</lname><age>25</age>

для изменения записи (lname и age останется без изменений):

PATCH /user/123
fname=Johnny

для обновления записи (и, следовательно,lname и age будет NULL):

PUT /user/123
fname=Johnny

отличная книга об отдыхе-это отдых на практике.

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

посмотреть Мартин ловящих статьи Модель Зрелости Ричардсона (RMM) для объяснения того, что такое служба RESTful.

чтобы быть RESTful служба должна выполнить гипермедиа как двигатель применения Государство. (HATEOAS), то есть он должен достичь уровня 3 в RMM, Читать статью для деталей или слайды из QCon talk.

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

...

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

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

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

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

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

что такое отдых?

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

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

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

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

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

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

http://rest.elkstein.org/

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

вместо использования определенного URL-адреса для удаления метода (скажем,/user/123/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

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

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

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

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

узнать отдых: учебник

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

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

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

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

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

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

объяснение отдыха и гипертекста: спам-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 не является спокойным, поэтому полезно увидеть точные причины этого. (SOAP-это тип RPC.)

Что такое отдых?

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

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

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

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

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

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

термин RESTful был создан, потому что ppl исчерпал слово REST, вызвав их приложение non-REST как REST. после этого термин RESTful также был исчерпан. в настоящее время мы говорим о Web Апис и гипермедиа Апис, потому что большинство так называемых приложений REST не выполнили часть HATEOAS ограничения uniform interface.

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

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

   поэтому он не работает, например, с гнездами PUB/SUB, он основан на REQ / REP.

2. коммуникации

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

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

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

4. единый интерфейс, единый договор между клиентом и сервер

   договор между клиентом и сервером не поддерживается сервером. Другими словами, клиент должен быть отделен от реализации сервиса. Вы можете достичь этого состояния с помощью стандартных решений, таких как стандарт IRI (URI) для идентификации ресурсов, стандарт HTTP для обмена сообщениями, стандартные типы MIME для описания формата сериализации тела, метаданные (возможно, RDF vocabs, микроформаты и т. д.) для описания семантики различных частей тело сообщения. Чтобы отделить структуру IRI от клиента, вы должны отправить гиперссылки клиентам в форматах гипермедиа, таких как (HTML, JSON-LD, HAL и т. д.). Таким образом, клиент может использовать метаданные (возможно, связи ссылок, RDF vocabs), назначенные гиперссылкам, для навигации по государственной машине приложения через соответствующие переходы состояния для достижения его текущей цели.

   например, когда клиент хочет отправить заказ в интернет-магазин, он должен проверить гиперссылки в ответах интернет-магазине. Проверяя ссылки, он находит тот, который описан с помощью http://schema.org/OrderAction. Клиент знает schema.org vocab, поэтому он понимает, что, активировав эту гиперссылку, он отправит заказ. Таким образом, он активирует гиперссылку и отправляет POST https://example.com/api/v1/order сообщение с соответствующим телом. После этого служба обрабатывает сообщение и отвечает результатом, имеющим соответствующий заголовок состояния HTTP, например 201 - created успех. Комментировать сообщения с подробными метаданными стандартное решение для использования формата RDF, например JSON-LD С помощью REST vocab, например Гидра и домен конкретных vocabs, как schema.org или любой другой связанные данные vocab и, возможно, пользовательское приложение конкретного vocab, если это необходимо. Теперь это непросто, поэтому большинство ppl используют HAL и другие простые форматы, которые обычно предоставляют только REST vocab, но не связанные данные поддержка.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

бонус:

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

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

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

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

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

только мой 2c.

Edit: еще два важных аспекта:

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

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

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

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

ИМО:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

приложение restful, если оно предоставляет ресурсы (будучи сочетание элементов управления data + state transitions) в типе носителя клиент понимает

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

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

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

REST === HTTP аналогия не верна, пока вы не подчеркнете тот факт, что она "должна" быть HATEOAS действие.

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

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

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

остальное - архитектурный стиль, основанный на веб-стандартах и протоколе HTTP (введен в 2000 году).

в архитектуре на основе REST все является ресурсом (пользователи, заказы, комментарии). Доступ к ресурсу осуществляется через общий интерфейс на основе стандартных методов HTTP (GET, PUT, PATCH, DELETE и т. д.).

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

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

REST позволяет, чтобы ресурсы имели разные представления, например, текст, XML,JSON и т. д. Клиент REST может запросить определенное представление по протоколу HTTP (согласование содержимого).

HTTP-методы:

методы PUT, GET, POST и DELETE типичны для архитектур на основе REST. В следующей таблице приводится описание этих операций.

• GET определяет доступ для чтения ресурса без побочных эффектов. Ресурс никогда не изменяется с помощью запроса GET, например, запрос не имеет побочных эффектов (идемпотент).
• PUT создает новый ресурс. Он также должен быть идемпотентным.
• DELETE удаляет ресурсы. Операции являются идемпотентными. Они могут повторяться без разные результаты.
• POST обновляет существующий ресурс или создает новый ресурс.

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

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

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

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

1. единый интерфейс
2. клиент–сервер
4. Cacheable
5. многоуровневая система
6. код по требованию (опционально)

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

что это тестирование API?

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

REST API

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

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

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

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

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

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

1. установить POSTMAN(Chrome) / REST (Firefox) плагин
2. введите URL API
3. выберите метод REST
4. выберите content-Header
5. введите запрос JSON (POST)
6. нажмите "Отправить".
7. он будет возвращать ответ

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

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

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

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

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

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

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

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