Что такое rest архитектура

Основы REST: теория и практика

REST, Representational State Transfer, является архитектурным стилем для обеспечения стандартов между компьютерными системами в сети, что облегчает для систем обмен данными друг с другом. Системы, отвечающие требованиям REST и часто называемые RESTful, характеризуются тем, что не имеют сохранения состояния и разделяют интересы клиента и сервера. Мы рассмотрим, что означают эти термины и почему они являются полезными для услуг в Интернете.

Разделение клиента и сервера

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

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

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

Отсутствие сохранения состояния

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

27–29 декабря, Онлайн, Беcплатно

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

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

Взаимодействие между клиентом и сервером

В архитектуре REST клиенты отправляют запросы на поиск или изменение ресурсов, а серверы отправляют ответы на эти запросы. Давайте рассмотрим стандартные способы направления запросов и ответов.

Отправка запросов

REST требует, чтобы клиент сделал запрос на сервер для получения или изменения данных на сервере. Запрос обычно состоит из:

Существует 4 основных метода НТТР, которые мы используем в запросах для взаимодействия с ресурсами в системе REST:

В заголовке запроса клиент отправляет тип контента, который он может получить с сервера. Это поле называется Accept. Оно обеспечивает, что сервер не посылает данные, которые не могут быть поняты или обработаны клиентом. Параметры типов контента — это типы MIME (или Multipurpose Internet Mail Extensions, о которых вы можете прочитать больше в MDN Web Docs).

Типы MIME, используемые для указания типов контента в поле Accept, состоят из типа и подтипа. Они разделены слэшем (/).

Другие типы и часто используемые подтипы:

Например, клиент, имеющий доступ к ресурсу с идентификатором 123 в ресурсе статей на сервере, может отправить запрос GET следующим образом:

Запросы должны содержать путь к ресурсу, на котором должна выполняться операция. В RESTful API пути должны быть разработаны так, чтобы помочь клиенту понять, что происходит. Обычно первая часть пути должна быть множественной формой ресурса. Это позволяет легко читать и понимать вложенные пути.

Пути должны содержать информацию, необходимую для определения местоположения ресурса с необходимой степенью конкретности. При ссылке на список или коллекцию ресурсов не всегда необходимо добавлять идентификатор. Например, запрос POST на путь somesite.com/persons не будет нуждаться в дополнительном идентификаторе, так как сервер генерирует идентификатор для нового объекта.

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

Например, клиент получает доступ к ресурсу с идентификатором 123 в разделе статей с этим запросом GET:

Сервер должен отправить обратно контент с заголовком ответа:

Это означает, что запрашиваемый контент возвращается в тело ответа с text/html — типом контента, который клиент будет в состоянии принять.

Коды ответов

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

Для каждого метода НТТР ожидаются коды статуса, которые сервер должен вернуть в случае успеха:

Если операция не работает, вернётся наиболее конкретный код состояния, соответствующий возникшей проблеме.

Предположим, у нас есть приложение, которое позволяет вам просматривать, создавать, редактировать и удалять клиентов и заказы для небольшого магазина одежды, размещённого на сайте fashionboutique.com. Мы можем создать НТТР API, который позволит клиенту выполнять следующие функции.

Если бы мы хотели увидеть всех клиентов, запрос выглядел бы так:

Возможный заголовок ответа будет выглядеть следующим образом:

Создание нового клиента путем размещения данных:

Затем сервер генерирует идентификатор этого объекта и возвращает его клиенту с таким заголовком:

Для просмотра одного клиента мы используем метод GET, указывая идентификатор этого клиента:

Возможный заголовок ответа будет выглядеть следующим образом:

Мы можем обновить этого клиента, вставив новые данные с помощью метода PUT:

Мы также можем УДАЛИТЬ этого клиента, указав его идентификатор:

Практика с REST

Давайте представим, что мы создаём сайт для сбора фотографий. Мы хотим сделать API, чтобы отслеживать пользователей, места проведения и фотографии этих мест. Этот сайт имеет index.html и style.css. Каждый пользователь имеет имя пользователя и пароль. Каждая фотография имеет место проведения и владельца (т.е. пользователя, который сделал фотографию). Каждое место имеет название и адрес. Можете ли вы разработать систему REST, которая будет учитывать:

Для начала опишите:

Источник

А ваша служба является RESTful? Все что необходимо/обязательно знать про веб службы и REST

Введение

Вот не люблю я изобретать велосипед и статью я бы эту не написал, но пришлось. Про REST сказано уже довольно много. Многие поставщики веб служб готовы клясться, что их службы являются RESTful. Во время собеседования вы точно услышите хотя бы несколько вопросов про REST, независимо от того это собеседования для бэкенд, мобайл или фронтенд разработчика. Я вот помню как-то во время одного собеседования меня задали такой вопрос: «Вот вы написали в своем резюме, что знайте REST․ Ответьте пожалуйста, какой HTTP код вы получите, если при запросе к RESTful сервису ресурс не найден?». Ответ 404 был принят единогласно. Если честно, я так и не понял, как этот вопрос помог понять знаю ли я REST или нет, но одно могу уверенно сказать: REST понимают далеко не все. Вот некоторые вопросы, которые мучали меня долгое время:

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

Ну что же, начнем путешествие в мир веб-сервисов.

SOA & Web Services

SOA, расширяемая как сервис ориентированная архитектура (Service Oriented Architecture), является парадигмой для организации и использования распределенных систем, которые могут находиться под контролем различных областей собственности [1]. В SOA, под service подразумевается функциональная возможность, которая удовлетворяет следующим критериям [2]։

Web Service, согласно определению [3], является системой, предназначенная для взаимодействия машин/программ по сети. Веб-сервис должен иметь интерфейс, описанной в машинно-обрабатываемом формате (service description). Другие системы должны взаимодействовать с веб-сервисом посредством сообщений.

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

Если вас заинтересует какие еще методы существуют или существовали для реализации SOA, можете посмотреть COM и CORBA.

Протоколы веб служб

До того, как решить какая служба является RESTful, а какая нет, рассмотрим некоторые реализации, или как по другому их называют, протоколы веб служб. Список общеизвестных протоколов веб служб можно найти в [4].

Протокол XML-RPC (XML Remote Procedure Call) [5] был в первые опубликован в 1999 году. Все сообщение XML-RPC являются HTTP-POST запросами. Для кодирования сообщений используется XML. Параметры процедуры могут быть скалярные значения, числа, строки, даты, массивы и структуры. Ответ веб службы может хранить либо значение, возвращаемой процедурой, либо код и сообщение ошибки.

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

Протокол JSON-RPC [6], опубликованный в 2009 году, по своим принципам работы очень похож на XML-RPC. Главными отличиями являются способ кодирования данных, независимость от транспортного уровня, способность передачи извещений (notification request) и возможность идентификации ответов при отправке нескольких запросов одновременно.

Для кодирования данных в JSON-RPC используется JSON. Кроме имени процедуры и параметров, в запросе указывается также значение id, который используется для идентификации ответа на стороне клиента. Другими словами если вы отправили запрос с то ответ этого запроса обязательно должен возвращать сообщение с >
Извещение – это специальные запросы, на которые сервер может не отвечать. Для отметки запроса, как извещение, значения параметра id указывается = null.

Независимость от транспортного уровня можно обусловить только тем, что в спецификации JSON-RPC [6] HTTP не указывается обязательным протоколом. При использовании JSON-RPC над HTTP, необходимо использовать POST запросы.

Недостатком JSON-RPC, как и в случае XML-RPC является отсутствие языка описания веб-сервиса (аналог WSDL).

Протокол SOAP (Simple Object Access Protocol) [7] является наследником XML-RPC. Основными характеристиками SOAP являются:

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

На самом деле REST вовсе не является протоколом и оно вообще не новое. REST является архитектурой который был предложен в 2000-ие годы Роем Филдингом в его диссертации «Architectural Styles and the Design of Network-based Software Architectures» [8]. До этого REST архитектура была использована в многих проектах в рамках IETF и W3C. В самой диссертации вы не сумейте найти терминов «веб служба» или SOA. REST архитектура была предложена для правильного конструирования распределенных гипермедиа систем, по другим словом того, что на сегодня называется World Wide Web. Чтобы диссертацию Филдинга вы приняли в серьез, скажу, что Рой является архитектором HTTP 1.1, соавтором интернет стандартов для HTTP и URI [10]. В общем мужик он серьезный и известный.

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

Для получения универсального интерфейса вводятся следующие ограничения:

В REST ресурсом является все то, чему можно дать имя. Например, пользователь, HTML документ, изображение, регистрированный пользователь, красная майка, голодная собака, текущая погода и т.д. Каждый ресурс в REST должен быть идентифицирован посредством стабильного идентификатора, который не меняется при изменении состояния ресурса. В нашем случае идентификатором в REST является URI.

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

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

Данный пункт означает, что гипертекст должен быть использован для навигации по API [9]. Отмечу, что в случае SOA для этого используется service description.

Рассмотрим данный пункт более подробно.

Как вы уже заметили в этих пунктах ничего не сказано про GET, PUT, POST и DELETE запросы, кодирование JSON, HTTP и т.д.

REST – это просто архитектура, он никак не привязан к каким либо протоколом.

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

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

REST & Richardson Maturity Model

И так, как же связан REST с веб службами? Какие службы можно считать RESTful, а какие нет? Что вы получите, если ваша служба будет удовлетворять всем пунктам Филдинга? Отвечу на эти вопросы по очереди:

REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and
encapsulate legacy systems.

Звучит конечно все очень круто, но надо ли чтобы ваш веб-сервис был сконструирован по REST или это просто тренд? Давайте рассмотрим модель RMM (Richardson Maturity Model) Леонарда Ричардсона.

После анализа нескольких сотен веб-сервисов [11] был предложен модель RMM для оценки качества, или как Ричардсон назвал это, зрелости веб-сервиса. Модель RMM состоит из 4 уровней. Если ваш сервис соответствует последнему уровню, то можно считать его RESTful. Ниже я приведу примеры и рисунки из [12], которые по словам автора были проверены Аароном Шварцем, Леонардом Ричардсоном и другими известными лицами. Все примеры основаны на следующей истории: Я хочу записаться на прием к врачу. От веб службы мне нужно получить свободные часы приема на конкретную дату и после записаться на прием. И так, рассмотрим все эти четыре уровня на данном примере.

Уровень 0: Один URI, один HTTP метод.

Здесь HTTP используется только для взаимодействия компонентов распределенной системы. Из методов используется только один, например POST. Как вы уже догадались, такими веб-сервисами являются протоколы XML-RPC и SOAP.

XML используется тут только для примера, в его месте мог был быть JSON, HTML и т.д. Веб-сервис имеет только один URL (относительный URL): /appointmentService. Запрашиваемая функция указывается в теле запроса.

Если ваш сервис соответствует уровню 0, то он еще ребенок.

Теперь рассмотрим этот же пример при работе с веб-сервисом с уровнем 1.

Уровень 1: Несколько URI, один HTTP метод.

Службы этого уровня используют понятие «разделяй и властвуй». В службе вводится понятие ресурсов и для действия с конкретным ресурсом используется URL этого ресурса.

И так, если вы хотите выполнить какое-то действие с доктором, то надо использовать относительный URL /doctors, а если ваше действие связано с посещением, то URL /slots. Если сравнить службу первого уровня со службой нулевого уровня, то в последнем случае есть только один ресурс, и этот ресурс сама веб служба.

Если ваш сервис соответствует уровню 1, то он является подростком.

Уровень 2: Несколько URI, каждый поддерживает разные HTTP методы (Правильное использование HTTP).

И так, на уровне 1 все методы веб службы были отделены с помощью ресурсов, но с ресурсом можно выполнить кучу действий. Чтобы эти действия тоже были как-то логически разделены, используется возможность HTTP отправлять и принимать операции с разними методами: GET, HEAD, POST, PUT, DELETE, TRACE, CONECT. Например, если метод является чтением, можно использовать GET, если для создания POST или PUT․ В принципе, можно и наоборот, но поскольку в HTTP эти методы имеют какие-то понятия и характеристики, лучше, чтобы эти понятия были те же, что и в веб службе, в противном случае вы можете получить кэшируемый метод создания ресурса. Другими словами, какой метод вы будете использовать для каких операций, уже вопрос правильного использования протокола HTTP․

Наверное, пришло время для примеров:

С вводом разных HTTP методов вводится также необходимость возвращения правильных HTTP статус кодов. Например, на запрос создания встречи, если она создана, то должен быть возвращен код 201. Если в течении ваших действий кто-то уже регистрировался на выбранный день и час, должен быть возвращен код 409 conflict и т.д. Опять же, тут дело в правильном использовании протокола HTTP․

Если ваш сервис соответствует уровню 2, то он является уже взрослым мужчиной.

Уровень 3: HATEOAS․ Ресурсы сами описывают свои возможности и взаимосвязи.

HATEOAS (Hypertext as the Engine of Application State), требование которое на мой взгляд обязательно для гипермедиа, но насколько это актуально для веб служб — не знаю. Все же, HATEOAS – это характеристика веб-сервиса возвращать действия в виде URL, которые могут быть выполнены с интересующим вам ресурсом.

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

Каждый свободный час имеет URL, для выполнения действий над ним, в этом случае регистрация на этот час.

Преимуществом HATEOAS является то, что оно дает возможность разработчикам веб служб менять URI независимо от клиентов. Кроме этого, веб-сервис сам описывает себя без каких-либо WSDL. Чтобы правильно представить HATEOAS, представьте веб сайт из статических страниц. Вы открывайте главную страницу, а там уже ссылки на все остальное. Чтобы зайти на веб сайт и что-то найти там, нет необходимости прочитать какой-то документ по данному веб сайту, что-то вроде документа по API. Опять же, мое субъективное мнение по необходимости веб-сервиса поддерживать HATEOAS довольно пессимистично.

Если ваш сервис соответствует уровню 3, то его можно уже называть RESTful ну и конечно стариком с хорошим опытом.

Заключение

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

Поскольку второй случай более распространенный чем первый, приведу основные концепции:

Источник

ИТ База знаний

Полезно

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

REST – что это? Сделай POST и отдохни

Рой Филдинг, который смог

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

Онлайн курс по Linux

Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps

REST: что это?

REST на практике

Если нет пустых прослоек, данные будут переданы в виде, аналогичном им самим. «Заворачивание» информации в XML не происходит, как в случае с SOAP и XML-RPC, также не используется и AMF, как это бывает с Flash. По сути, происходит чистая передача.

Контроль информации сервиса

Поэтому Create/Read/Update/Delete-действия будут выполнены и с 4 указанными алгоритмами, и посредством GET и POST. Это позволит в некоторых случаях обойти негативные эффекты с использованием непринятых PUT и DELETE.

REST в построении веб-сервисов

Для любой информационной единицы можно задать 5 вариантов действия:

Итоги

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

Для чего можно использовать?

Источник

SAP@Pitroff.Ru

“REST” – это не про “отдых”.
Часть первая: что такое архитектура REST?

Disclaimer:
1) Часть 1 – теоретическая, может быть скучно :);
2) если вы до этого сталкивались и работали с протоколом HTTP (знаете, как устроен, формат запроса/ответа) – проблем с пониманием REST у вас возникнуть не должно. Если не уверены – рекомендую сначала почитать
про HTTP на Википедии.

Из википедии: REST (Representational State Transfer) — архитектурный стиль взаимодействия компонентов распределённого приложения в сети.

Для веб-сервисов или API, построенных с учётом REST (то есть не нарушающих накладываемых им ограничений), применяют термин «RESTful».

Термин REST был введен в 2000 году Роем Филдингом, одним из авторов HTTP-протокола.

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

Очень важно следующее: REST – это НЕ протокол или стандарт.
В отличие от веб-сервисов на основе SOAP, не существует утвержденного или принятого официально стандарта для RESTful сервисов. REST является архитектурой, в то время как SOAP является протоколом.

То есть REST – это набор принципов и ограничений взаимодействия клиента и сервера в сети интернет, использующий существующие стандарты (HTTP протокол, стандарт построения URL, форматы данных JSON и XML) в ходе взаимодействия.

Правила и ограничения REST-архитектуры

В REST есть шесть основных ограничений:

1) Модель взаимодействия клиент-сервер.

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

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

2) Отсутствие состояния.

3) Кэширование.

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

4) Единообразие интерфейса.

Чтобы отделить один ресурс(сервис) от другого используются запросы/ссылки (URI).

Пример: информация по ISBN-коду книги в библиотеке – http://library.net/books/info/
продление книги по ISBN – http://library.net/books/prolong/

Пример неподходящего разделения: http://library/books/operation, где операция и код книги должны быть в теле запроса.

По простому: если мы получили мета-данные по объекту (из предыдущего примера – код ISBN книги) – то можем сделать с этим объектом любую операцию из состава API.

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

Гипермедиа – это расширение термина гипертекст. Если упростить – то это все интерактивные объекты сети: рисунки, схемы, видео (пример – youtube), текст и ссылки.

5) Слои.

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

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

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

RESTful сервис

С точки зрения пользователя, RESTful сервисы – это ресурсы сети, которыми может быть всё, что можно поименовать и представить.

Сервисы описывают себя сами. Ну или пытаются :), но чем логичней и понятней система наименования (url) – тем удобнее работать с API.
Поэтому api/books/get/ISBN/2-266-11156 лучше и понятней, с точки зрения клиента, чем /api?obj=books&func=get&search=ISBN&number=2-266-11156

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

Пример: Используя REST API находим книгу по url api/books/get/ISBN/2-266-11156. В ответе сервис высылает блок информации, в нем есть элемент infolink, содержащий ссылку api/books/info/2-266-11156.

Взаимодействие с ресурсами осуществляется с помощью вызова URL ресурса и стандартных команд HTTP (GET, POST, PUT и DELETE). Эти операции обычно соответствуют операциям с объектом, например, так:

Ответ сервис также отправляет в виде кода возврата HTTP, например:

На деле кодов возврата у HTTP существенно больше (wiki – HTTP codes). Также дополнительные данные об ошибке могут передаваться в теле ответа.

Формат данных, передаваемых между клиентом и сервисом указывается с помощью заголовка HTTP – параметр типа содержимого Content-Type. Обычно это JSON или XML, но могут быть разнообразными (например, JPG, PNG – для сервиса обработки графики).

JSON vs XML

Для специалистов, работающих с SAP PI/PO, XML – это практически второй родной язык. 🙂 JSON же в мире SAP практически не используется, поэтому уделю немного внимания этой теме.

Сходство JSON и XML:
Это понятные языки – их можно читать без специального ПО и понимать содержимое;
Это иерархичные языки – данные организованы при помощи различных уровней вложенности;
Для получения данных/значений XML/JSON нужно разобрать – подвергнуть “парсингу”,”распарсить”.

Основные различия:
JSON компактнее (данные в формате JSON имеют меньший размер, чем в XML);
JSON быстрее в чтении/передаче данных;
JSON позволяет вариативность типов/структур (например, в JSON-схеме разрешены элементы, имеющие один из нескольких типов – в схеме данных можно определить, что элемент price может быть текстом, а может быть структурой из двух элементов). После привычки к строгости XML вариативность JSON сложно понять и принять. 🙂

Использование REST API

На данный момент практически каждый крупный интернет-ресурс имеет свой REST API:

А вот как с ним работать – будет в следующей серии. 🙂

2 thoughts on “ “REST” – это не про “отдых”.
Часть первая: что такое архитектура REST? ”

Ура, появляются новые статьи 🙂 Жду вторую часть.

Источник