1. Программные интерфейсы. Определение. Предназначение. Краткая характеристика. Возможная классификация.
-
API (программный интерфейс приложения) — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой. Обычно входит в описание какого-либо интернет-протокола, программного каркаса или стандарта вызовов функций операционной системы. Часто реализуется отдельной программной библиотекой или сервисом операционной системы. Используется программистами при написании всевозможных приложений.
-
API упрощает процесс программирования при создании приложений, абстрагируя базовую реализацию и предоставляя только объекты или действия, необходимые разработчику.
Интерфейсы функционально-ориентированного программирования знают только функции с возвращаемым значением или без него как средства связи. Практически всегда используется концепция ручек . Вы вызываете функцию и получаете ее дескриптор. Этот дескриптор можно использовать для вызова других функций, пока дескриптор не будет снова закрыт.
Интерфейсы программирования File-ориентированных выходят за пределы обычных вызовов файловой системы open, read, writeи closeимя. Если данные должны быть отправлены объекту, они также writeзаписываются; если они должны быть получены, они также readчитаются. Этот принцип широко распространен в UNIX при управлении драйверами устройств.
В интерфейсах объектно-ориентированного программирования используются указатели на интерфейсы, поэтому они значительно более гибкие, чем интерфейсы функционально-ориентированного программирования. Часто предоставляется библиотека типов .
Программные интерфейсы, ориентированные на протокол, не зависят от операционной системы и оборудования . Однако протокол всегда нужно повторно внедрять. Чтобы свести к минимуму эти усилия, интерфейс, ориентированный на протокол, инкапсулируется в интерфейс, ориентированный на функции или интерфейс. Здесь также можно провести различие между общими (например, SOAP ) и специфическими для приложений (например, SMTP ) протоколами.
- API (программный интерфейс приложения) — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой. Обычно входит в описание какого-либо интернет-протокола, программного каркаса или стандарта вызовов функций операционной системы. Часто реализуется отдельной программной библиотекой или сервисом операционной системы. Используется программистами при написании всевозможных приложений.
Есть три метода взаимодействия с API:
- Процесс, который может выполнять программа при помощи этого интерфейса.
- Данные, которые нужно передать интерфейсу для выполнения им функции.
- Данные, которые программа получит на выходе после работы с API.
Разработчикам программный интерфейс позволяет:
- Упростить и ускорить выпуск новых продуктов, так как можно использовать уже готовые API для стандартных функций;
- Сделать разработку более безопасной, выведя ряд функций в отдельное приложение, где они будут скрыты;
- Упростить настройку связей между разными сервисами и программами и не сотрудничать для разработки своего продукта с создателями различных приложений;
- Сэкономить деньги, так как не нужно разрабатывать все программные решения с нуля.
Подробнее на РБК: https://trends.rbc.ru/trends/industry/614b2abe9a79476f5b552e0e
-
API (программный интерфейс приложения) — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой. Обычно входит в описание какого-либо интернет-протокола, программного каркаса или стандарта вызовов функций операционной системы. Часто реализуется отдельной программной библиотекой или сервисом операционной системы. Используется программистами при написании всевозможных приложений.
-
Тестирование API — это тип тестирования программного обеспечения, который определяет, соответствует ли недавно разработанное приложение ожиданиям с точки зрения надежности, производительности, операций и безопасности.
-
Убедиться, что реализация API работает правильно, как и ожидалось - без ошибок!
-
Гарантировать, что реализация API работает в соответствии со спецификацией требований (которая позже становится нашей документацией по API).
-
Предотвратить регрессий между написанным кодом(merge) и релизом.
Каждый тест состоит из тестовых шагов. Это отдельные атомарные действия, которые тест должен выполнять в каждом потоке тестирования API. Для каждого запроса API тест должен будет выполнить следующие действия:
-
Проверьте корректность кода состояния HTTP. Например, создание ресурса должно возвращать 201 CREATED, а запрещенные запросы должны возвращать 403 FORBIDDEN и т. Д.
-
Проверьте полезную нагрузку ответа. Проверьте правильность тела JSON, имен, типов и значений полей ответа, в том числе в ответах на ошибочные запросы.
-
Проверьте заголовки ответа. Заголовки HTTP-сервера влияют как на безопасность, так и на производительность.
-
Проверьте правильность состояния приложения. Это необязательно и применяется в основном к ручному тестированию или когда пользовательский интерфейс или другой интерфейс можно легко проверить.
-
Проверьте базовую работоспособность. Если операция была завершена успешно, но заняла неоправданно много времени, тест не пройден.
4. Что такое программный интерфейс. Дайте определение программному интерфейсу. Расскажите о трёх основных элементах API.
- API (программный интерфейс приложения) — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой. Обычно входит в описание какого-либо интернет-протокола, программного каркаса или стандарта вызовов функций операционной системы. Часто реализуется отдельной программной библиотекой или сервисом операционной системы. Используется программистами при написании всевозможных приложений.
- Интерфейс используется для того, чтобы получить доступ к тому, что работает «под капотом». Данный интерфейс обычно предоставляется с помощью таких общеупотребимых протоколов, как HTTP, Thrift, TCP/IP и т. д., и опирается на стандартизированные форматы JSON, XML или HTML.
- Реализация — это тот элемент системы, который предоставляет саму ее функциональность. Часто реализация написана на языке программирования, например Java, C#, Ruby или Python.
- Экземпляр приложения с API — это комбинация интерфейса и реализации. Это удобный способ говорить о существующем API, который уже запущен в производственной среде.
5. Дайте определение API. В чём различия между интерфейсом, реализацией, экземпляром приложения с API.
-
API (программный интерфейс приложения) — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой. Обычно входит в описание какого-либо интернет-протокола, программного каркаса или стандарта вызовов функций операционной системы. Часто реализуется отдельной программной библиотекой или сервисом операционной системы. Используется программистами при написании всевозможных приложений.
-
Интерфейс используется для того, чтобы получить доступ к тому, что работает «под капотом». Данный интерфейс обычно предоставляется с помощью таких общеупотребимых протоколов, как HTTP, Thrift, TCP/IP и т. д., и опирается на стандартизированные форматы JSON, XML или HTML.
-
Реализация — это тот элемент системы, который предоставляет саму ее функциональность. Часто реализация написана на языке программирования, например Java, C#, Ruby или Python.
-
Экземпляр приложения с API — это комбинация интерфейса и реализации. Это удобный способ говорить о существующем API, который уже запущен в производственной среде.
6. Дайте определение API. В чём различия между интерфейсом, реализацией, экземпляром приложения с API. Зачем необходимо разделять интерфейс и реализацию.
Под понятием интерфейc принято понимать набор средств, используемых для взаимодействия двух систем. Объединение отдельных подсистем (устройств, модулей) ЭВМ в единую систему основывается на многоуровневом принципе с унифицированным сопряжением между всеми уровнями — стандартным интерфейсом.
- Интерфейс используется для того, чтобы получить доступ к тому, что работает «под капотом». Данный интерфейс обычно предоставляется с помощью таких общеупотребимых протоколов, как HTTP, Thrift, TCP/IP и т. д., и опирается на стандартизированные форматы JSON, XML или HTML.
- Реализация — это тот элемент системы, который предоставляет саму ее функциональность. Часто реализация написана на языке программирования, например Java, C#, Ruby или Python.
- Экземпляр приложения с API — это комбинация интерфейса и реализации. Это удобный способ говорить о существующем API, который уже запущен в производственной среде.
Разделение кода позволяет менять реализацию, сохраняя интерфейс.
Например, у вас может быть API, отображающий задачи управления учетными записями пользователей. Этот интерфейс может позволить разработчикам:
- открыть новую учетную запись;
- редактировать профиль уже существующей учетной записи;
- изменить (заморозить или активировать) статус учетной записи Функциональность описанной реализации — это простой набор действий по схеме «создать, прочесть, обновить, удалить» (CRUD), тогда как в упомянутом интерфейсе есть три действия: OnboardAccount (Активировать учетную запись), EditAccount (Редактировать учетную запись) и ChangeAccountStatus (Изменить статус учетной записи).
-
API (программный интерфейс приложения) — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой. Обычно входит в описание какого-либо интернет-протокола, программного каркаса или стандарта вызовов функций операционной системы. Часто реализуется отдельной программной библиотекой или сервисом операционной системы. Используется программистами при написании всевозможных приложений.
-
Веб-API - это интерфейс прикладного программирования для веб-сервера или веб-браузера. Это концепция веб-разработки, обычно ограниченная клиентской стороной веб-приложения (включая любые используемые веб-фреймворки), и поэтому обычно не включает детали реализации веб-сервера или браузера, такие как SAPI или API, если они не доступны для общего доступа через удаленное веб-приложение.
API и веб-сервис служат средством коммуникации. Единственное различие заключается в том, что веб-сервис облегчает взаимодействие между двумя машинами по сети. API работает как интерфейс между двумя различными приложениями, чтобы они могли общаться друг с другом. API - это метод, с помощью которого сторонние поставщики могут писать программы, которые легко взаимодействуют с другими программами. Веб-служба предназначена для интерфейса, который изображается в машинопроцессорном формате, обычно указанном в языке описания веб-служб (WSDL). Как правило, «HTTP» является наиболее часто используемым протоколом для связи.
Открытые API - интерфейсы предлагаются в качестве сервиса или продукта другими; вы не создаете их, не устанавливаете и не запускаете – вы только используете их (API социальных сетей, операционных систем и т.д.) Закрытый API – это API, который вы создаете для себя: его используют только приложения, созданные вами или сотрудниками вашей команды, отдела или компании (API для связи бекенда и фронтенда, API в рамках микросервисной архитектуры).
Между закрытыми и открытыми API могут быть различные виды взаимодействия!
-
API (программный интерфейс приложения) — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой. Обычно входит в описание какого-либо интернет-протокола, программного каркаса или стандарта вызовов функций операционной системы. Часто реализуется отдельной программной библиотекой или сервисом операционной системы. Используется программистами при написании всевозможных приложений.
-
Веб-служба — идентифицируемая уникальным веб-адресом (URL-адресом) программная система со стандартизированными интерфейсами
API и веб-сервис служат средством коммуникации. Единственное различие заключается в том, что веб-сервис облегчает взаимодействие между двумя машинами по сети. API работает как интерфейс между двумя различными приложениями, чтобы они могли общаться друг с другом. API - это метод, с помощью которого сторонние поставщики могут писать программы, которые легко взаимодействуют с другими программами. Веб-служба предназначена для интерфейса, который изображается в машинопроцессорном формате, обычно указанном в языке описания веб-служб (WSDL). Как правило, «HTTP» является наиболее часто используемым протоколом для связи.
Связность — это мера того, насколько отдельная компонента образует логически законченную, осмысленную единицу. Высокая связность достигается объединением в одной компоненте соотносящихся (в том или ином смысле) друг с другом функций. Наиболее часто функции оказываются связанными друг с другом при необходимости иметь доступ к общим данным. Именно это объединяет разные части компоненты Recipe.
Зацепление — характеризует взаимозависимость между компонентами программы. В общем случае желательно уменьшить степень зацепления как только возможно, поскольку связи между компонентами программы препятствуют их модификации и мешают дальнейшей разработке или повторному использованию в других программах.
В частности, зацепление возникает, если одна программная компонента должна иметь доступ к данным (состоянию) другой компоненты.
Ресурсы являются фундаментальными строительными блоками веб-систем в той степени, в которой Интернет часто называют «ресурсо-ориентированным». Ресурс - это все, что мы предоставляем в Интернете, от документа или видеоклипа до бизнес-процесса или устройства.
Ресурс становится веб-ресурсом, просто делая информацию, связанную с ним, доступной в сети
В основе REST лежит ресурсно-ориентированный подход, в котором центральное место отводится объектам (ресурсам). Клиенту достаточно знать простую фиксированную точку входа в приложение и MIME-типы ресурсов, для работы с которыми он предназначен
URI — символьная строка, позволяющая идентифицировать какой-либо ресурс: документ, изображение, файл, службу, ящик электронной почты и т. д. Прежде всего, речь идёт о ресурсах сети Интернет и Всемирной паутины. URI предоставляет простой и расширяемый способ идентификации ресурсов. Расширяемость URI означает, что уже существуют несколько схем идентификации внутри URI, и ещё больше будет создано в будущем.
URI имеет вид <схема>: <структура-схемы>. http://example.org ftp://example.org/reports/book.txt
Схема определяет, как следует интерпретировать остальную часть идентификатора. Например, http-часть URI, такая как http://example.org/reports/book.tar сообщает нам, что остальная часть URI должна интерпретироваться в соответствии со схемой HTTP.
URL-адреса и URN - это особые формы URI. URI, который идентифицирует механизм, с помощью которого можно получить доступ к ресурсу, обычно называется URL-адресом. HTTP URI являются примерами URL-адресов. Если URI имеет urn в качестве схемы и соответствует требованиям RFC 2141 и RFC 2611, то это URN. Цель URN - предоставить глобально уникальные имена для ресурсов.
URN — это постоянная последовательность символов, идентифицирующая абстрактный или физический ресурс. URN является частью концепции URI
urn:isbn:5170224575 urn:oid:2.16.643
URL был разработан как система для максимально естественного указания на местонахождения ресурсов в сети. Локатор должен был быть легко расширяемым и использовать лишь ограниченный набор ASCII‐символов (к примеру, в URL никогда не применяется пробел). В связи с этим возникла следующая традиционная форма записи URL:
Изначально URL предназначался для обозначения мест расположения ресурсов (чаще всего файлов) во Всемирной паутине. Сейчас URL применяется для обозначения адресов почти всех ресурсов Интернета
15. Представление ресурсов. Определение. Приведите несколько примеров предствления ресурсов, используемых в вебе.
Представление - это преобразование или вид (view) о состоянии ресурса в определенный момент времени. Представление закодировано в одном или нескольких переносимых форматах, таких как XHTML, Atom, XML, JSON, обычный текст, значения, разделенные запятыми, MP3 или JPEG и т.д. Доступ к ресурсу всегда осуществляется через его представления. URI связывают, соединяют представления со своими ресурсами в сети.
JSON - это общий формат данных с минимальным количеством типов значений - строки, числа, булевы значения (единица или ноль), списки, объекты и нуль.
JSON является открытым стандартом формата файла и обмена данными в формате , который использует читаемый человеком текст для хранения и передачи данных объектов , состоящих из пары и массивы атрибут – значение (или другие сериализуемые значения).
JSON-объект — это неупорядоченное множество пар «ключ:значение». Ключ — это название параметра, который мы передаем серверу. Он служит маркером для принимающей запрос системы
XML (расширяемый язык разметки) — это язык программирования для создания логической структуры данных, их хранения и передачи в виде, удобном и для компьютера, и для человека. Отличается простотой синтаксиса и универсальностью.
Особенности XML:
-
Разметка XML файла позволяет описывать его содержание.
-
XML документ способен нести информацию о включённом в него материале. Он несет информацию только о структуре и смысле документа, оставляя форматирование элементов таблице стилей (Extensible Stylesheet Language, XSL).
-
Сведения о содержании файла могут быть затем повторно использованы на различных компьютерах и в различных приложениях.
-
Способность объединять несколько XML документов в один большой документ.
-
Для XML не обязательно определение типа документа.
-
Теги XML можно применять для управления поиском информации, в том числе и в глобальных сетях.
-
XML предоставляет пользователю возможность определения своего собственного способа кодирования информации с использованием языка разметки.
-
XML может употребляться в качестве формата обмена для протоколов транзакций.
XML предназначен для хранения и передачи данных, а HTML — для их отображения. Теги HTML предопределены. Современные браузеры знают о них и могут соответствующим образом отобразить информацию, заключенную в тегах HTML. Теги XML не предопределены, они задаются разработчиком, браузеры о них не знают
JSON является открытым стандартом формата файла и обмена данными в формате , который использует читаемый человеком текст для хранения и передачи данных объектов , состоящих из пары и массивы атрибут – значение (или другие сериализуемые значения).
XML - это язык разметки, который определяет набор правил для кодирования документов в формате, который удобен для чтения человеком и компьютером. Были разработаны сотни форматов документов с использованием синтаксиса XML, включая RSS , Atom , SOAP , SVG и XHTML. XML — используется в SOAP (всегда) и REST- запросах (реже).
JSON превосходит XML в простоте и легкости обработки данных. Более читаемый, легче расширяемый, в архитектуре REST используется JSON. XML применяется в SOAP
Ресурсы являются фундаментальными строительными блоками веб-систем в той степени, в которой Интернет часто называют «ресурсо-ориентированным». Ресурс - это все, что мы предоставляем в Интернете, от документа или видеоклипа до бизнес-процесса или устройства.
В современном распределенном системном мышлении популярна идея, что набор глаголов, поддерживаемых HTTP - GET, POST, PUT, DELETE, OPTIONS, HEAD, TRACE, CONNECT и PATCH - образует достаточно универсальный протокол для поддержки широкого спектра решений, в том числе и для взаимодействия с ресурсами
HTTP - это протокол высокого уровня (а именно, уровня приложений), обеспечивающий необходимую скорость передачи данных, требующуюся для распределенных информационных систем гипермедиа. HTTP используется проектом World Wide Web с 1990 года.
HTTP/1.0 предоставляет открытое множество методов, которые могут быть использованы для указания целей запроса. Они построены на дисциплине ссылок, где для указания ресурса, к которому должен быть применен данный метод, используется Универсальный Идентификатор Ресурсов
HTTP/1.0 используется также для коммуникаций между различными пользовательскими просмотрщиками и шлюзами, дающими гипермедиа доступ к существующим Internet протоколам, таким как SMTP, NNTP, FTP, Gopher и WAIS. HTTP/1.0 разработан, чтобы позволять таким шлюзам через proxy серверы, без какой-либо потери передавать данные с помощью упомянутых протоколов более ранних версий
21. Что такое HTTP глаголы? Приведите примеры. Каково предназначение HTTP глаголов при разработке WEB API?
HTTP-глаголы — это элемент протокола HTTP, который используется в каждом запросе, чтобы указать, какое действие нужно выполнить над данным ресурсом.
Главное здесь то, что мы рассматриваем некоторые объекты (ресурсы) и совершаем над ними некоторые действия, которые определены в протоколе списком HTTP-методов: GET, PUT, POST, DELETE и т.д
Главное в методах HTTP заключается в том, что они обеспечивают единый интерфейс, что является ключевым принципом REST.
- GET - запрашивает представление ресурса. Запросы с использованием этого метода могут только извлекать данные.
- HEAD - запрашивает ресурс так же, как и метод GET, но без тела ответа.
- POST - используется для отправки сущностей к определённому ресурсу. Часто вызывает изменение состояния или какие-то побочные эффекты на сервере.
- PUT - заменяет все текущие представления ресурса данными запроса.
- DELETE - удаляет указанный ресурс.
- CONNECT - устанавливает "туннель" к серверу, определённому по ресурсу.
- OPTIONS - используется для описания параметров соединения с ресурсом.
- TRACE - выполняет вызов возвращаемого тестового сообщения с ресурса.
- PATCH - используется для частичного изменения ресурса.
HTTP - это протокол высокого уровня (а именно, уровня приложений), обеспечивающий необходимую скорость передачи данных, требующуюся для распределенных информационных систем гипермедиа. HTTP используется проектом World Wide Web с 1990 года.
В соответствии со спецификацией OSI, HTTP является протоколом прикладного (верхнего, 7-го) уровня
Протокол RFC2616 описывает взаимодействие между двумя компьютерами (клиентом и сервером), построенное на базе сообщений, называемых запрос (Request) и ответ (Response). Каждое сообщение состоит из трех частей: стартовая строка, заголовки и тело. При этом обязательной является только стартовая строка.
Спецификация HTTP не обязывает сервер понимать все методы — обязателен только GET, а также не указывает серверу, что он должен делать при получении запроса с тем или иным методом. Сервер в ответ на запрос DELETE /index.php HTTP/1.1 не обязан удалять страницу index.php на сервере, так же как на запрос GET /index.php HTTP/1.1 не обязан возвращать вам страницу index.php, он может ее удалять.
Оркестровка служб представляет собой единый централизованный исполняемый бизнес-процесс (оркестратор), который координирует взаимодействие между различными службами. Организатор отвечает за вызов и объединение служб.
Отношения между всеми участвующими службами описываются одной конечной точкой (т. е. составной службой). Согласование включает в себя управление транзакциями между отдельными службами. В оркестровке используется централизованный подход к составу услуг.
Хореография сервиса-это глобальное описание участвующих сервисов, которое определяется обменом сообщениями, правилами взаимодействия и соглашениями между двумя или более конечными точками. Хореография использует децентрализованный подход к композиции услуг.
Хореография описывает взаимодействие между несколькими службами, где оркестровка as представляет собой контроль с точки зрения одной стороны. Это означает, что хореография отличается от оркестровки в отношении того, где должна находиться логика, управляющая взаимодействием между задействованными службами.
JSON-RPC — протокол удалённого вызова процедур, использующий JSON для кодирования сообщений. Это очень простой протокол (очень похожий на XML-RPC), определяющий только несколько типов данных и команд. JSON-RPC поддерживает уведомления (информация, отправляемая на сервер, не требует ответа) и множественные вызовы.
Преимущества RPC
- Простота и понятность взаимодействий. RPC использует GET для получения информации и POST для всего остального. Механика взаимодействия между сервером и клиентом сводится к вызову конечной точки и получению ответа.
- Легкость добавления функций. Получив новое требование для API, мы можем легко добавить другую конечную точку, выполняющую это требование: 1) написать новую функцию и перебросить ее на конечную точку, и 2) теперь клиент может попасть в эту конечную точку и получить информацию, соответствующую заданному требованию.
- Высокая производительность. Легкие полезные нагрузки легко распределяются по сети, обеспечивая высокую производительность, что важно для общих серверов и параллельных вычислений, выполняемых в сетях рабочих станций. RPC способен оптимизировать сетевой уровень и сделать его очень эффективным в ситуации, когда различные сервисы каждый день обмениваются тоннами сообщений.
Недостатки RPC
- Плотная связь с базовой системой. Уровень абстракции API способствует его повторному использованию. Чем теснее связанность с базовой системой, тем хуже API подходит для других систем. Тесная связь RPC с базовой системой не позволяет создать уровень абстракции между функциями в системе и внешним API. Отсюда вытекают вопросы относительно безопасности, поскольку детали реализации базовой системы довольно легко просачиваются в API. Плотная связанность RPC создает трудности для требований к масштабируемости и слабо связанных команды. Таким образом, клиент либо беспокоится о возможных побочных эффектах вызова определенной конечной точки, либо пытается выяснить, какую конечную точку следует вызвать, потому что не понимает, по какому принципу сервер именует функции.
- Низкая обнаруживаемость. В RPC нет никакого способа интроспектировать API или отправить запрос и начать понимать, какую функцию вызывать на основе его запросов.
- Взрыв функций. Новые функции создавать очень легко. Поэтому вместо того, чтобы редактировать существующие, мы создаем новые, в результате чего получаем огромный список перекрывающихся функций, которые трудно понять.
Примеры использования RPC Шаблон RPC получил первое применение примерно в 80-х годах, но это само по себе не делает его устаревшим. Крупные компании, такие как Google, Facebook (Apache Thrift) и Twitch (Twirp), используют внутри себя высокопроизводительные вариации RPC для чрезвычайно высокопроизводительного обмена сообщениями с низкими накладными расходами. Их массивные системы микросервисов требуют, чтобы внутренняя коммуникация была четкой и в то же время организованной в короткие сообщения. API для команд. RPC — подходящий выбор для отправки команд в удаленную систему. Например, Slack API очень командно-ориентирован: зайти на канал, покинуть канал, отправить сообщение. Разработчики Slack API как раз и смоделировали его в стиле RPC, сделав его маленьким, компактным и простым в использовании. Клиентские API для внутренних микросервисов. В случае прямой интеграции между единственным поставщиком и потребителем не хочется тратить много времени на передачу большого количества метаданных, как это делает REST API. gRPC и Twirp очень подходят для микросервисов благодаря высокой скорости передачи сообщений и их производительности. gRPC, с HTTP2 под капотом, способен оптимизировать сетевой уровень и повысить его эффективность при отправке с одного сервиса на другой тонн сообщений в день. Однако, если вы стремитесь не к высокой производительности сети, а к стабильному API-контакту между командами, публикующими очень отличающиеся друг от друга микросервисы, REST позаботится об этом лучше.
Удалённый вызов процедур — Протокол, позволяющий программе на одном компьютере выполнить некоторый программный код на другом компьютере; причём от создателя программы не требуется знание подробностей механизма взаимодействия между компьютерами.
Удаленный вызов процедуры включает следующие шаги:
-
Программа-клиент производит локальный вызов процедуры, называемой заглушкой (stub). При этом клиенту "кажется", что, вызывая заглушку, он производит собственно вызов процедуры-сервера. И действительно, клиент передает заглушке необходимые параметры, а она возвращает результат. Однако дело обстоит не совсем так, как это себе представляет клиент. Задача заглушки - принять аргументы, предназначаемые удаленной процедуре, возможно, преобразовать их в некий стандартный формат и сформировать сетевой запрос. Упаковка аргументов и создание сетевого запроса называется сборкой (marshalling).
-
Сетевой запрос пересылается по сети на удаленную систему. Для этого в заглушке используются соответствующие вызовы, например, рассмотренные в предыдущих разделах. Заметим, что при этом могут быть использованы различные транспортные протоколы, причем не только семейства TCP/IP.
-
На удаленном хосте все происходит в обратном порядке. Заглушка сервера ожидает запрос и при получении извлекает параметры - аргументы вызова процедуры. Извлечение (unmarshalling) может включать необходимые преобразования (например, изменения порядка расположения байтов).
-
Заглушка выполняет вызов настоящей процедуры-сервера, которой адресован запрос клиента, передавая ей полученные по сети аргументы.
-
После выполнения процедуры управление возвращается в заглушку сервера, передавая ей требуемые параметры. Как и заглушка клиента; заглушка сервера преобразует возвращенные процедурой значения, формируя сетевое сообщение-отклик, который передается по сети системе, от которой пришел запрос.
-
Операционная система передает полученное сообщение заглушке клиента, которая, после необходимого преобразования, передает значения (являющиеся значениями, возвращенными удаленной процедурой) клиенту, воспринимающему это как нормальный возврат из процедуры.
Существует три основных типа архитектур API: RPC, REST и SOAP
RPC ― это простой формат для отправки нескольких параметров и получения результатов. API RPC вызывают действия или процессы, в то время как другие API в основном обмениваются данными или ресурсами. RPC может использовать два разных языка для кодирования ― JSON и XML.
Формат SOAP использует только язык кодирования XML. Работа с API с этой архитектурой самая сложная: SOAP очень структурированный и строго контролируемый формат. SOAP используется, когда компании нужна повышенная безопасность и четко определенные правила для обменов данными. Разработчики часто используют SOAP для внутренних или партнерских API.
REST считается более простой альтернативой SOAP. Каждая единица информации для этого вида API ― уникальный URL-адрес, который можно запросить. REST используют для быстрого обмена простыми параметрами, из которых состоят базы данных. Поэтому REST API хорошо подходит для взаимодействия больших баз данных. Эти характеристики делают REST популярным для публичных API, например, для мобильных приложений.
XML-RPC — стандарт/протокол вызова удалённых процедур, использующий XML для кодирования своих сообщений и HTTP в качестве транспортного механизма. Сообщение XML-RPC переносится методом запроса HTTP, а ответ – в обычном ответе HTTP. Запрос обычно содержит XML-документ с корневым элементом , а ответ - XML- документ с корневым элементом . В настоящий момент имеется более 30 реализаций XML-RPC. Существует ряд библиотек, помогающих создавать программы, совместимые с XML-RPC. Они доступны для множества языков, включая C, C ++, Java, PERL, .NET и многие другие.
Особенности XML-RPC
- Трафик не шифруется и не аутентифицируется. Возможно использование протокола IPSec для защиты соединений между машинами.
- Можно легко изменить порядок параметров метода, который может быть обнаружен только во время выполнения (вызов метода класса XmlRpcClient) и передача параметров.
- Использует HTTP POST и XML для удаленных вызовов. XML-RPC пытается стандартизировать способ представления такой информации в полезных данных HTTP-запроса и ответа, чтобы различным приложениям не приходилось изобретать свои собственные форматы и сопоставления с системами типов.
28. Что такое протокол доступа к простым объектам(SOAP)? Как работает SOAP. Плюсы и минусы использования SOAP, как средства реализации API.
SOAP – реализует наиболее важный аспект web-сервисов – транспортировку данных по сети. SOAP расширяет HTTP для возможности передачи XML-сообщений, используемых для удалённого взаимодействия и для передачи целых XML-документов. Правила передачи информации в SOAP строго стандартизированы, есть спецификация, которой нужно соответствовать.
Преимущества SOAP API
- Стандартный протокол HTTP для SOAP упрощает работу через брандмауэры и прокси-серверы без изменения самого протокола SOAP. Но поскольку он использует сложный формат XML, он обычно работает медленнее по сравнению с промежуточным программным обеспечением, таким как ICE и CORBA.
- Кроме того, хотя это редко требуется, некоторые варианты использования требуют большей надежности транзакций, чем то, что может быть достигнуто с помощью HTTP (что ограничивает REST в этом качестве).
- В некоторых случаях разработка сервисов SOAP может быть менее сложной по сравнению с REST. Для веб-служб, которые поддерживают сложные операции, требующие поддержки содержимого и контекста, проектирование службы SOAP требует меньше кода на уровне приложения для транзакций, безопасности, доверия и других элементов.
- SOAP легко расширяется с помощью других протоколов и технологий. Помимо WS-Security, SOAP поддерживает WS-Addressing, WS-Coordination, WS-ReliableMessaging и множество других стандартов веб-сервисов.
Преимущества REST API
- REST допускает большее разнообразие форматов данных, тогда как SOAP допускает только XML.
- В сочетании с JSON (который обычно лучше работает с данными и предлагает более быстрый синтаксический анализ), REST обычно считается более простым в использовании.
- Благодаря JSON REST предлагает лучшую поддержку браузерных клиентов.
- REST обеспечивает превосходную производительность, особенно за счет кэширования неизменяемой и не динамической информации.
- Это протокол, который чаще всего используется для крупных сервисов, таких как Yahoo, eBay, Amazon и даже Google.
- REST обычно быстрее и использует меньше пропускной способности.
WSDL — это язык описания веб-сервиса, имеющий структуру XML. Основное назначение WSDL-файла — это интерфейс доступа к функциям сервиса, возвращаемым типам данных; путь к серверу, обрабатывающему запросы и т.д.
На веб-сервисе лежит файл WSDL. И клиент, и сервер руководствуются в своей работе этим файлом: читают его и разбираются, как устроен сервис. И клиент, и сервер умею читать этот файл и получать из него информацию, так как они знают стандарт SOAP и то, как должен быть устроен файл WSDL.
Давайте разберем этот wsdl-файл:
Operation — это тег, который описывает функции. То есть он указывает на имя функции и то, как должен выглядеть запрос и ответ.
Вложенные в operation теги input и output содержат информацию о входных и выходных параметрах функции. То есть getQuoteRequest — это запрос, который представляет собой строку и должен иметь вид числа с плавающей точкой.
Тег binding описывает все технические сведения, о том, что из себя представляет сервис.
Тег servisce описывает, где живет наш сервис. Если бы мы установили веб-сервисом на локальной машине, то адрес написали бы следующим образом: localhost/server1. php/.
Если вы захотите расписать WSDL в виде дерева, то получите следующую картину:
Термин «простой старый XML» (POX) - это ссылка на определенные типы или использование расширяемого языка разметки (XML), которые являются менее сложными или сложными, чем другие версии языка. В целом, POX относится к простым способам использования XML в проектах.
POX привлекателен как подход, потому что XML дает нам независимость от платформы, в то время как использование HTTP дает практически повсеместное соединение между системами. Однако архитектурный POX стиль эквивалентен XML-RPC и страдает теми же недостатками.
Одним из более технических определений POX является то, что это неукрашенный XML, который передается по простым протоколам, таким как HTTP, SMTP или FTP, или через какой-то проприетарный промежуточный продукт. POX также может быть технически определен как тип XML, который не обременен оболочками, такими как SOAP.
Модель зрелости Ричардсона (RMM) - это модель зрелости, предложенная в 2008 году Леонардом Ричардсоном, которая классифицирует веб-API на основе их соответствия и соответствия каждому из четырех уровней модели.
RMM можно использовать для определения того, насколько хорошо архитектура веб-службы соответствует принципам REST. Он классифицирует веб-API на четыре уровня (от 0 до 3), причем каждый более высокий уровень соответствует более полному соблюдению дизайна REST. Следующий уровень также содержит все характеристики предыдущего.
Уровень 0 Болото ОСПЫ Использование HTTP в качестве транспортной системы для удаленных взаимодействий, но без использования каких-либо механизмов веб.
Самый низкий уровень модели описывает веб-API с одним URI (обычно публикуется по протоколу HTTP), принимающим весь спектр операций, поддерживаемых службой. Ресурсы в этой форме не могут быть четко определены. Обмен сообщениями осуществляется в XML, JSON или других текстовых форматах. Это типичная ОСПА RPC и многие сервисы SOAP Уровень 1 Ресурсы Вместо того, чтобы делать запросы к отдельной конечной точке службы, мы начинаем «разговаривать» с отдельными ресурсами.
Вводит ресурсы и позволяет запрашивать отдельные URI (все еще обычно публикуемые) для отдельных действий вместо предоставления одной универсальной конечной точки (API). Ресурсы API по-прежнему обобщены, но можно определить область применения каждого из них. Уровень 2 HTTP-глаголы Система начинает использовать HTTP-глаголы. Это позволяет дополнительно специализировать ресурс и, таким образом, сузить функциональность каждой отдельной операции с сервисом. Принцип разделения на этом уровне заключается в разделении данного ресурса на два - один запрос только для получения данных (GET), другой для изменения данных (POST) Уровень 3 Последний уровень представляет представление гипермедиа. Также называемые HATEOAS (Гипермедиа Как Механизм состояния приложения), это элементы, встроенные в ответные сообщения ресурсов, которые позволяют устанавливать связь между отдельными объектами данных, возвращаемыми из API и передаваемыми в них.
Использование HTTP в качестве транспортной системы для удаленных взаимодействий, но без использования каких-либо механизмов веб. Существенной особенностью является использование НТТР как механизма туннелирования для вашего собственного механизма удаленного взаимодействия, обычно основанного на вызове удаленных процедур.
Пример уровня 0 XML используется тут только для примера, в его месте мог был быть JSON, HTML и т.д. Веб-сервис имеет только один URL (относительный URL): /appointmentService. Запрашиваемая функция указывается в теле запроса.
Модель (разработанная Леонардом Ричардсоном) разделяет основные элементы REST-подхода на 3 шага.
- ресурсы
- http-глаголы
- элементы управления гипермедиа
Уровень 1 - Ресурсы
Вместо того, чтобы делать запросы к отдельной конечной точке службы, мы начинаем «разговаривать» с отдельными ресурсами.
Пример: получение свободных часов доктора mjones на дату 2010-01-04
С первоначальным запросом у нас может быть ресурс для данного врача. Ответ содержит ту же основную информацию, но теперь каждый слот является ресурсом, который можно адресовать индивидуально.
Модель (разработанная Леонардом Ричардсоном) разделяет основные элементы REST-подхода на 3 шага.
- ресурсы
- http-глаголы
- элементы управления гипермедиа
Уровень 2 - HTTP-глаголы
На уровнях 0 и 1 HTTP глаголы используются как механизмы туннелирования, позволяющие туннелировать ваши взаимодействия через HTTP. Уровень 2 уходит от этого, используя глаголы HTTP как можно ближе к тому, как они используются в самом HTTP. Все методы веб службы были отделены с помощью ресурсов, но с ресурсом можно выполнить кучу действий. Чтобы эти действия тоже были как-то логически разделены, используется возможность HTTP отправлять и принимать операции с разними методами: GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT.
Пример для уровня 2:
С вводом разных HTTP методов вводится также необходимость возвращения правильных HTTP статус кодов. Например, на запрос создания встречи, если она создана, то должен быть возвращен код 201. Если в течении ваших действий кто- то уже регистрировался на выбранный день и час, должен быть возвращен код 409 conflict и т.д. Опять же, тут дело в правильном использовании протокола HTTP․
Модель (разработанная Леонардом Ричардсоном) разделяет основные элементы REST-подхода на 3 шага.
- ресурсы
- http-глаголы
- элементы управления гипермедиа
Уровень 3 - Элементы управления гипермедиа
Ресурсы сами описывают свои возможности и взаимосвязи. HATEOAS (Hypertext as the Engine of Application State)- (гипертекст как механизм состояния приложения). Суть элементов управления гипермедиа заключается в том, что они сообщают нам, что мы можем делать дальше, и URI ресурса, которым мы должны управлять, чтобы это сделать. Вместо того, чтобы знать, где разместить запрос о встрече, элементы управления гипермедиа в ответе сообщают нам, как это сделать.
Пример для уровня 3:
Одним из очевидных преимуществ элементов управления гипермедиа является то, что он позволяет серверу изменять свою схему URI, не нарушая работу клиентов. Например, пока клиенты ищут URI ссылки «addTest», серверная группа может манипулировать всеми URI, кроме начальных точек входа. Веб-сервис сам описывает себя без каких-либо WSDL. Не существует абсолютного стандарта в отношении того, как представлять элементы управления гипермедиа. RMM уровня 3 является предварительным условием REST
HATEOAS (Hypermedia as the Engine of Application State) — архитектурные ограничения для REST-приложений.
С помощью HATEOAS клиент взаимодействует с сетевым приложением, сервер которого обеспечивает динамический доступ через гипермедиа. REST-клиенту не требуется заранее знать, как взаимодействовать с приложением или сервером за пределом гипермедиа.
В отличие от архитектуры SOA, где взаимодействие клиента с сервером строго определены интерфейсом, HATEOAS отделяет клиента от сервера и позволяет им независимо развиваться.
REST-клиент обращается к фиксированному URL, а все последующие действия клиента становятся известными из возвращаемых с сервера ресурсов. Типы ресурсов, представления и их связи стандартизированы. Клиент проходит по ресурсам, выбирая ссылки или взаимодействуя любым другим способом, возможным для этого типа ресурса. Таким образом RESTful-взаимодействия работают через гипермедиа, а не через заранее указанный интерфейс.
Например, сделать запрос возвращающий ресурс счёта в XML-представлении
GET /accounts/12345 HTTP/1.1
Host: bank.example.com
Accept: application/xml
...
Ответ будет таким:
HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: ...
<?xml version="1.0"?>
<account>
<account_number>12345</account_number>
<balance currency="usd">100.00</balance>
<link rel="deposit" href="https://bank.example.com/accounts/12345/deposit" />
<link rel="withdraw" href="https://bank.example.com/accounts/12345/withdraw" />
<link rel="transfer" href="https://bank.example.com/accounts/12345/transfer" />
<link rel="close" href="https://bank.example.com/accounts/12345/close" />
</account>
Ответ содержит ссылки на депозит, снятие, перевод и закрытие аккаунта В случае отрицательного баланса, доступен только депозит:
HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: ...
<?xml version="1.0"?>
<account>
<account_number>12345</account_number>
<balance currency="usd">-25.00</balance>
<link rel="deposit" href="https://bank.example.com/account/12345/deposit" />
</account>
Теперь доступна только одна ссылка: внести больше денег. Отсюда «the Engine of Application State» в названии. Возможные действия различаются в зависимости от состояния ресурса.
Клиенту не нужно знать заранее типы ресурсов и механизмы взаимодействия с ним, через сервер. Понимание новых типов ресурсов приобретается в режиме реального времени, во время исполнения, при получении ресурсов от сервера.
REpresentational State Transfer («передача состояния представления») REST - это архитектурный стиль для разработки сетевых приложений (т. е. приложений, которые используют некоторую форму сети для связи). Это самый популярный стиль для создания веб-API. REST определяет спецификации API с помощью набора правил, которые соблюдаются при создании REST API.
Распределенная система, организованная RESTfully, улучшится в следующие направления:
- Производительность
- Масштабируемость взаимодействия компонентов
- Простота интерфейса
- Возможность модификации компонентов
- Переносимость
- Надежность
- Видимость
Особенности терминологии REST и RESTful
REST - это относительно новый способ создания веб-службы, который использует протокол HTTP для предоставления веб-служб.
REST - это стиль архитектуры программного обеспечения. Как описано в диссертации Роя Филдинга, REST - это «архитектурный стиль», который в основном использует существующие технологии и протоколы Интернета.
RESTful обычно используется для обозначения веб-служб, реализующих такую архитектуру.
RESTful обычно используется для обозначения веб-служб, реализующих архитектуру REST.
Некоторые ключевые характеристики REST включают в себя:
- REST не имеет состояния, поэтому у SERVER нет состояния (или данных сеанса)
- С помощью хорошо примененного REST API сервер может быть перезапущен между двумя вызовами, поскольку все данные передаются на сервер.
- Веб-сервис в основном использует метод POST для выполнения операций, тогда как REST использует GET для доступа к ресурсам.
REpresentational State Transfer («передача состояния представления») REST - это архитектурный стиль для разработки сетевых приложений (т. е. приложений, которые используют некоторую форму сети для связи). Это самый популярный стиль для создания веб-API. REST определяет спецификации API с помощью набора правил, которые соблюдаются при создании REST API.
Преимущества REST API
- REST допускает большее разнообразие форматов данных, тогда как SOAP допускает только XML.
- В сочетании с JSON (который обычно лучше работает с данными и предлагает более быстрый синтаксический анализ), REST обычно считается более простым в использовании.
- Благодаря JSON REST предлагает лучшую поддержку браузерных клиентов.
- REST обеспечивает превосходную производительность, особенно за счет кэширования неизменяемой и не динамической информации.
- Это протокол, который чаще всего используется для крупных сервисов, таких как Yahoo, eBay, Amazon и даже Google.
- REST обычно быстрее и использует меньше пропускной способности.
Преимущества SOAP API
- Стандартный протокол HTTP для SOAP упрощает работу через брандмауэры и прокси-серверы без изменения самого протокола SOAP. Но поскольку он использует сложный формат XML, он обычно работает медленнее по сравнению с промежуточным программным обеспечением, таким как ICE и CORBA.
- Кроме того, хотя это редко требуется, некоторые варианты использования требуют большей надежности транзакций, чем то, что может быть достигнуто с помощью HTTP (что ограничивает REST в этом качестве).
- В некоторых случаях разработка сервисов SOAP может быть менее сложной по сравнению с REST. Для веб-служб, которые поддерживают сложные операции, требующие поддержки содержимого и контекста, проектирование службы SOAP требует меньше кода на уровне приложения для транзакций, безопасности, доверия и других элементов.
- SOAP легко расширяется с помощью других протоколов и технологий. Помимо WS-Security, SOAP поддерживает WS-Addressing, WS-Coordination, WS-ReliableMessaging и множество других стандартов веб-сервисов.
40. Что такое CRUD? Примеры задач, демонстрирующих необходимость использования дополнительных глаголов HTTP.
CRUD — акроним, обозначающий четыре базовые функции, используемые при работе с базами данных: создание (англ. create), чтение (read), модификация (update), удаление (delete). Введён Джеймсом Мартином (англ. James Martin) в 1983 году как стандартная классификация функций по манипуляции данными.
Пример задачи, которая демонстрирует необходимость дополнительных глаголов
Для частей заказа в бизнес-процессе кафе мы хотим создавать, читать, обновлять и удалять ресурсы заказов, например:
- Заказы создаются, когда покупатель совершает покупку. (CREATE)
- Заказы читаются часто, особенно когда запрашивается их текущий статус. (READ)
- При определенных условиях заказы могут обновляться (например, в тех случаях, когда клиенты передумают или добавляют фирменные блюда к своим напиткам). (UPDATE)
- Наконец, если заказ все еще ожидает обработки, покупателю может быть разрешено отменить его (или удалить). (DELETE)
REpresentational State Transfer («передача состояния представления») REST - это архитектурный стиль для разработки сетевых приложений (т. е. приложений, которые используют некоторую форму сети для связи). Это самый популярный стиль для создания веб-API. REST определяет спецификации API с помощью набора правил, которые соблюдаются при создании REST API.
Как и любой другой архитектурный стиль, REST также имеет 6 собственных направляющих ограничений, которые должны быть удовлетворены, если интерфейс должен называться REST.
Руководящие принципы REST
- Клиент-сервер
Сервер отвечает за обработку набора сервисов и слушает запросы, касающиеся этих сервисов. В запросы, в свою очередь, отправляются через соединитель клиентской системой, нуждающейся в одной из этих служб. Главный принцип этого ограничения - разделение ответственности. Это позволяет разделить внешний код (представление и возможные процессы, связанные с пользовательским интерфейсом).
- Без сохранения состояния
Коммуникация между клиентом и сервером не должна иметь состояния, что означает, что каждый запрос, сделанный от клиента, должен иметь все информацию, необходимую серверу для ее понимания, без использования каких- либо сохраненных данных.
- Ограничения кеширования
Предлагается, чтобы каждый ответ на запрос должен быть явно или неявно установлен как кэшируемый (если применимо). На стороне сервера некоторые взаимодействия (например, запрос к базе данных) полностью игнорируются, в то время как контент кешируется.
- Единый интерфейс
Реализация клиента не зависит от вашей, поэтому, определив стандартный и единый интерфейс для всех ваших сервисов, вы эффективно упростили реализацию независимых клиентов.
- Многоуровневая система
Разделяя компоненты на уровни и позволяя каждому слою использовать только тот, который находится ниже, и передавать свои выходные данные вышестоящему, вы упрощаете общую сложность системы и контролируете взаимосвязь компонентов.
- Код по запросу (необязательно)
Клиент может загружать и выполнять код, предоставленный сервером (например, апплеты Java, сценарии JavaScript и т. Д.). В случае REST API это ограничение кажется ненужным, потому что обычно клиент API просто получает информацию от конечной точки, а затем обрабатывает ее по мере необходимости.
Руководящие принципы REST
- Клиент-сервер
Сервер отвечает за обработку набора сервисов и слушает запросы, касающиеся этих сервисов. В запросы, в свою очередь, отправляются через соединитель клиентской системой, нуждающейся в одной из этих служб. Главный принцип этого ограничения - разделение ответственности. Это позволяет разделить внешний код (представление и возможные процессы, связанные с пользовательским интерфейсом).
- Без сохранения состояния
- Ограничения кеширования
- Единый интерфейс
- Многоуровневая система
- Код по запросу (необязательно)
Руководящие принципы REST
- Клиент-сервер
- Без сохранения состояния
Коммуникация между клиентом и сервером не должна иметь состояния, что означает, что каждый запрос, сделанный от клиента, должен иметь все информацию, необходимую серверу для ее понимания, без использования каких- либо сохраненных данных.
- Ограничения кеширования
- Единый интерфейс
- Многоуровневая система
- Код по запросу (необязательно)
- Клиент-сервер
- Без сохранения состояния
- Ограничения кеширования
- Единый интерфейс
Реализация клиента не зависит от вашей, поэтому, определив стандартный и единый интерфейс для всех ваших сервисов, вы эффективно упростили реализацию независимых клиентов.
- Многоуровневая система
- Код по запросу (необязательно)
- Клиент-сервер
- Без сохранения состояния
- Ограничения кеширования
- Единый интерфейс
- Многоуровневая система
Разделяя компоненты на уровни и позволяя каждому слою использовать только тот, который находится ниже, и передавать свои выходные данные вышестоящему, вы упрощаете общую сложность системы и контролируете взаимосвязь компонентов.
- Код по запросу (необязательно)
- Клиент-сервер
- Без сохранения состояния
- Ограничения кеширования
- Единый интерфейс
- Многоуровневая система
- Код по запросу (необязательно)
Клиент может загружать и выполнять код, предоставленный сервером (например, апплеты Java, сценарии JavaScript и т. Д.). В случае REST API это ограничение кажется ненужным, потому что обычно клиент API просто получает информацию от конечной точки, а затем обрабатывает ее по мере необходимости.
Основными строительными блоками архитектуры REST являются ресурсы.
Все, что можно назвать, может быть ресурсом (веб- страница, изображение, человек, отчет службы погоды и т. Д.). Ресурсы определяют, для чего будут использоваться услуги, тип информации, которая будет передаваться, и связанные с ними действия.
Ресурс - это абстракция всего, что можно концептуализировать (от файла изображения до простого текстового документа).
Идентификатор ресурса должен обеспечивать уникальный способ идентификации в любой момент времени и обеспечивать полный путь к ресурсу. Классическая ошибка - предполагать, что это идентификатор ресурса на используемом носителе.
Все ресурсы идентифицируются в запросах, например, с использованием URI в интернет-системах. Ресурсы концептуально отделены от представлений, которые возвращаются клиентам. Например, сервер может отсылать данные из базы данных в виде HTML, XML или JSON, ни один из которых не является типом хранения внутри сервера.
Идентификатор ресурса должен обеспечивать уникальный способ идентификации в любой момент времени и обеспечивать полный путь к ресурсу. Классическая ошибка - предполагать, что это идентификатор ресурса на используемом носителе.
- Представление
- Идентификатор
- Метаданные
- Контрольные данные
Представление
По своей сути представление - это набор байтов и некоторые метаданные, описывающие эти байты. Единый ресурс может иметь более одного представления. Есть два очень популярных способа позволить клиенту запросить конкретное представление о ресурсе.
Согласование содержания
Первый напрямую следует принципам, описанным REST (при использовании HTTP в качестве основы), называется согласованием содержимого.
Он состоит из отправки клиентом определенного заголовка с информацией о различных типах контента. (или типы представлений) поддерживаются, с дополнительным индикатором того, насколько поддерживаются / предпочитаются формат.
Идентификатор ресурсов
Идентификатор ресурса должен обеспечивать уникальный способ идентификации в любой момент времени и обеспечивать полный путь к ресурсу. Классическая ошибка - предполагать, что это идентификатор ресурса на используемом носителе.
50. Как лучше всего создать стандартный URI для веб-службы в архитектуре REST? Best Practices представления ресурсов.
Best Practics для комплексных действий
Эмпирическое правило: скрывать сложность всех действий за знаком «?».
PUT /api/v1/blogposts/12342 ?action=like
GET /api/v1/books?q=[SEARCH-TERM]
GET /api/v1/authors?filters=[COMMA SEPARATED LIST OF FILTERS]
- Клиент-сервер
- Без сохранения состояния
- Ограничения кеширования
Предлагается, чтобы каждый ответ на запрос должен быть явно или неявно установлен как кэшируемый (если применимо). На стороне сервера некоторые взаимодействия (например, запрос к базе данных) полностью игнорируются, в то время как контент кешируется.
- Единый интерфейс
- Многоуровневая система
- Код по запросу (необязательно)
REpresentational State Transfer («передача состояния представления») REST - это архитектурный стиль для разработки сетевых приложений (т. е. приложений, которые используют некоторую форму сети для связи). Это самый популярный стиль для создания веб-API. REST определяет спецификации API с помощью набора правил, которые соблюдаются при создании REST API.
HATEOAS - Гипермедиа, как механизм состояния приложения
Структура ресурса содержит раздел, называемый метаданными; внутри этого раздела представление каждого ресурса должно содержать набор гипермедийных ссылок, которые позволяют клиенту знать, что делать с каждым ресурсом. Предоставляя эту информацию в самом ответе, любой клиент может предпринять следующие шаги, обеспечивая тем самым еще больший уровень взаимодействия между клиентом и сервером.
Единственная самая важная причина для HATEOAS — слабая связь (loose coupling). Если потребителю службы REST необходимо жестко закодировать все URL-адреса ресурсов, он тесно связан с реализацией вашей службы. Вместо этого, если вы вернете URL-адреса, которые он может использовать для действий, он будет слабосвязанным. Нет строгой зависимости от структуры URI, так как она указана и используется в ответе. Несколько важных тем, связанных с HATEOAS:
HAL — язык гипертекстовых приложений
При разработке службы RESTful необходимо указать, как возвращать данные и ссылки, соответствующие запросу. HAL — это формат, который обеспечивает простой и согласованный способ гиперссылки между ресурсами в вашем REST API.
С HAL у вас есть несколько категорий представлений:
- Links (Ссылки): указано как комбинация
- Target (Цель) — указана в качестве URI
- Relation (Отношение) — имя
- Embedded Resources (Встроенные ресурсы): другие ресурсы, содержащиеся в данном REST ресурсе
- State (Состояние): фактические данные ресурса
С помощью HATEOAS ответы на запросы REST возвращают не только данные, но и действия, которые можно выполнить с ресурсом.
Это помогает сделать приложения слабосвязанными.
HAL — язык гипертекстовых приложений
При разработке службы RESTful необходимо указать, как возвращать данные и ссылки, соответствующие запросу. HAL — это формат, который обеспечивает простой и согласованный способ гиперссылки между ресурсами в вашем REST API.
Это разрабатываемый (Internet Draft, или ID) стандарт для определения гипермедиа, таких как ссылки на внешние ресурсы в форматах JSON или XML. HAL структурирован таким образом, чтобы представлять элементы на основе двух концепций: ресурсы и связи. Ресурсы состоят из ссылок URI ресурсов внедренных в стандартные форматы данных (будь то JSON или XML) а не ссылок URI. Ссылки имеют целевой URI, имя (называемый 'rel'), а также дополнительные свойства, предназначенные для учета устаревания и согласования содержимого.
Вот как выглядит ссылка в документе HAL:
"_links": {
"self": { "href": "/orders" },
"next": { "href": "/orders?page=2" },
"find": { "href": "/orders{?id}"
, "templated": true } 1
}
Каждый link объект имеет идентификатор ( self, next, find). . Это идентификатор, который клиентское приложение будет хранить в коде, а не фактическое значение URL-адреса. URL-адреса отображаются в href свойстве, и эти URL- адреса могут быть шаблонами URL-адресов. HAL использует спецификацию шаблона URI (RFC6570) и templated:"true"свойство для них.
С HAL у вас есть несколько категорий представлений:
- Links (Ссылки): указано как комбинация
- Target (Цель) — указана в качестве URI
- Relation (Отношение) — имя
- Embedded Resources (Встроенные ресурсы): другие ресурсы, содержащиеся в данном REST ресурсе
- State (Состояние): фактические данные ресурса
54. Протокол HTTP. Коды состояния. Примеры. Какова цель кода состояния HTTP при реализации REST API?
Код состояния - это число, которое суммирует связанный с ним ответ. Пример, 404 для «Страница не найдена», 200 для «ОК»
Коды сгруппированы в пять наборов в зависимости от их значения:
- 1xx: информационный и определяется только в HTTP 1.1.
- 2xx: запрос выполнен, вот ваше содержание.
- 3xx: ресурс был каким-то образом куда-то перемещен.
- 4xx: источник запроса сделал что-то неправильно. • 5xx: сервер упал из-за ошибки в его коде.
Код ответа (состояния) HTTP показывает, был ли успешно выполнен определённый HTTP запрос, в ином случае помогает понять с чем возможно связана ошибка.
Метод HTTP является идемпотентным, если повторный идентичный запрос, сделанный один или несколько раз подряд, имеет один и тот же эффект, не изменяющий состояние сервера. Другими словами, идемпотентный метод не должен иметь никаких побочных эффектов (side-effects), кроме сбора статистики или подобных операций. Корректно реализованные методы GET, HEAD, PUT и DELETE идемпотентны, но не метод POST. Также все безопасные методы являются идемпотентными.
Для идемпотентности нужно рассматривать только изменение фактического внутреннего состояния сервера, а возвращаемые запросами коды статуса могут отличаться: первый вызов DELETE вернёт код 200, в то время как последующие вызовы вернут код 404. Из идемпотентности DELETE неявно следует, что разработчики не должны использовать метод DELETE при реализации RESTful API с функциональностью удалить последнюю запись.
Обратите внимание, что идемпотентность метода не гарантируется сервером, и некоторые приложения могут нарушать ограничение идемпотентности.
GET /pageX HTTP/1.1 идемпотентен. Вызвавший несколько раз подряд этот запрос, клиент получит тот же результат:
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
POST /add_row HTTP/1.1 не идемпотентен; если его вызвать несколько раз, то он добавит несколько строк:
POST /add_row HTTP/1.1
POST /add_row HTTP/1.1 -> Adds a 2nd row
POST /add_row HTTP/1.1 -> Adds a 3rd row
DELETE /idX/delete HTTP/1.1 идемпотентен, даже если возвращаемый код отличается:
DELETE /idX/delete HTTP/1.1 -> Returns 200 if idX exists
DELETE /idX/delete HTTP/1.1 -> Returns 404 as it just got deleted
DELETE /idX/delete HTTP/1.1 -> Returns 404
56. Основные компоненты HTTP-запроса. С помощью какого компонента происходит передача данных в рамках REST архитектуры.
HTTP запросы - это сообщения, отправляемые клиентом, чтобы инициировать реакцию со стороны сервера. Их стартовая строка состоит из трёх элементов:
Стартовая строка
-
Метод HTTP, глагол (например, GET, PUT или POST) или существительное (например, HEAD или OPTIONS), описывающие требуемое действие. Например, GET указывает, что нужно доставить некоторый ресурс, а POST означает отправку данных на сервер (для создания или модификации ресурса, или генерации возвращаемого документа).
-
Цель запроса, обычно URL, или абсолютный путь протокола, порт и домен обычно характеризуются контекстом запроса. Формат цели запроса зависит от используемого HTTP-метода.
-
Версия HTTP, определяющая структуру оставшегося сообщения, указывая, какую версию предполагается использовать для ответа.
Заголовки
Заголовки запроса HTTP имеют стандартную для заголовка HTTP структуру: не зависящая от регистра строка, завершаемая (':') и значение, структура которого определяется заголовком. Весь заголовок, включая значение, представляет собой одну строку, которая может быть довольно длинной.
Существует множество заголовков запроса. Их можно разделить на несколько групп:
- Основные заголовки (General headers), например, Via (en-US), относящиеся к сообщению в целом
- Заголовки запроса (Request headers), например, User-Agent, Accept-Type, уточняющие запрос (как, например, Accept-Language), придающие контекст (как Referer), или накладывающие ограничения на условия (like If-None).
- Заголовки сущности, например Content-Length, относящиеся к телу сообщения. Как легко понять, они отсутствуют, если у запроса нет тела.
Тело
Последней частью запроса является его тело. Оно бывает не у всех запросов: запросы, собирающие (fetching) ресурсы, такие как GET, HEAD, DELETE, или OPTIONS, в нем обычно не нуждаются. Но некоторые запросы отправляют на сервер данные для обновления, как это часто бывает с запросами POST (содержащими данные HTML-форм).
Тела можно грубо разделить на две категории:
-
Одноресурсные тела (Single-resource bodies), состоящие из одного отдельного файла, определяемого двумя заголовками: Content-Type и Content-Length.
-
Многоресурсные тела (Multiple-resource bodies), состоящие из множества частей, каждая из которых содержит свой бит информации. Они обычно связаны с HTML-формами.
Строка статуса (Status line)
Стартовая строка ответа HTTP, называемая строкой статуса, содержит следующую информацию:
- Версию протокола, обычно HTTP/1.1.
- Код состояния (status code), показывающая, был ли запрос успешным. Примеры: 200, 404 или 302
- Пояснение (status text). Краткое текстовое описание кода состояния, помогающее пользователю понять сообщение HTTP.
Пример строки статуса: HTTP/1.1 404 Not Found.
Заголовки
Заголовки ответов HTTP имеют ту же структуру, что и все остальные заголовки: не зависящая от регистра строка, завершаемая двоеточием (':') и значение, структура которого определяется типом заголовка. Весь заголовок, включая значение, представляет собой одну строку.
Существует множество заголовков ответов. Их можно разделить на несколько групп:
-
Основные заголовки (General headers), например, Via (en-US), относящиеся к сообщению в целом.
-
Заголовки ответа (Response headers), например, Vary и Accept-Ranges, сообщающие дополнительную информацию о сервере, которая не уместилась в строку состояния.
-
Заголовки сущности (Entity headers), например, Content-Length, относящиеся к телу ответа. Отсутствуют, если у запроса нет тела.
Тело
Последней частью ответа является его тело. Оно есть не у всех ответов: у ответов с кодом состояния, например, 201 или 204, оно обычно отсутствует.
Тела можно разделить на три категории:
- Одноресурсные тела (Single-resource bodies), состоящие из отдельного файла известной длины, определяемые двумя заголовками: Content-Type и Content-Length.
- Одноресурсные тела (Single-resource bodies), состоящие из отдельного файла неизвестной длины, разбитого на небольшие части (chunks) с заголовком Transfer-Encoding (en-US), значением которого является chunked.
- Многоресурсные тела (Multiple-resource bodies), состоящие из многокомпонентного тела, каждая часть которого содержит свой сегмент информации. Они относительно редки.
58. Что такое Developer eXperience? Как Developer eXperience влияет на проектирование и разработку API?
При разработке и проектировании API необходимо принять во внимание ключевой аспект: Developer eXperience (или DX). Опыт разработчика (DX) описывает опыт разработчиков при использовании или работе над вашим продуктом.
Необходимо найти компромисс между простой и более сложной архитектурой. Далее даются некоторые рекомендации по хорошему DX.
Протокол связи, как элемент DX
При выборе протокола связи всегда рекомендуется использовать тот, который знаком разработчикам, использующим API. Существует несколько стандартов, в которых уже есть библиотеки и модули, доступные на многих языках программирования (например, HTTP, FTP, SSH и т. Д.).
Легко запоминающиеся точки доступа, как элемент DX
Точки контакта между всеми клиентскими приложениями и API называются конечными точками. API должен предоставить их, чтобы клиенты могли получить доступ к его функциям. Это можно сделать с помощью любого выбранного протокола связи. Эти точки доступа должны иметь мнемотехнические имена, чтобы разработчик мог понять их назначение, просто прочитав их.
Единый интерфейс, как элемент DX
Нужно быть последовательным, при определении имен конечных точек, форматов запросов и ответов.
Пример несовместимого интерфейса, можно увидеть на языке программирования PHP. PHP имеет обозначение подчеркивания в именах большинства функций, но в некоторых функциях подчеркивание не используется. Например, str_replace - это функция, которая использует подчеркивание для разделения обоих слов (str и replace), тогда как htmlentities вообще не разделяет слова.
Пример плохой практики проектирования в API - присвоение имен конечным точкам на основе предпринятых действий, а не обработанных ресурсов
/getAllBooks
/submitNewBook
/updateAuthor
/getBooksAuthors
/getNumberOfBooksOnStock
OAuth 1.0a, OAuth 2.0, Digest Auth и Basic Auth + TSL - самые популярные методы аутентификации в наши дни. Они прекрасно работают, они реализованы на всех современных языках программирования.
Базовая аутентификация с TSL
- Сначала клиент делает запрос ресурса без специального заголовка.
- Сервер отвечает неавторизованным ответом 401 и в нем заголовком WWWAuthenticate, в котором указывается используемый метод (базовый или дайджест) и имя области.
- Затем клиент отправляет тот же запрос, но добавляет заголовок авторизации со строкой USERNAME: PASSWORD, закодированной в BASE64. Нарушается принцип «без сохранения состояния»
Безопасный метод ничего не меняет внутри (ресурсы) Идемпотентный метод ничего не меняет внешне (ответ)
Безопасные методы - это методы, которые можно кэшировать с предварительной выборкой без каких-либо последствий для ресурса. Идемпотентный HTTP-метод - это HTTP-метод, который можно вызывать многократно без разных результатов.
Метод запроса считается «идемпотентным», если предполагаемое воздействие на сервер нескольких идентичных запросов с помощью этого метода такое же, как влияние для одного такого запроса. Из методов запроса, определенных в этой спецификации, PUT, DELETE и безопасные методы запроса являются идемпотентными.
Как и определение сейфа, свойство идемпотента применяется только к тому, что было запрошено пользователем; сервер может регистрировать каждый запрос отдельно, сохранять историю контроля версий или реализовывать другие неидемпотентные побочные эффекты для каждого идемпотентного запроса.
Идемпотентные методы отличаются тем, что запрос может повторяться автоматически, если сбой связи происходит до того, как клиент сможет прочитать ответ сервера. Например, если клиент отправляет запрос PUT и основное соединение закрывается до получения какого-либо ответа, тогда клиент может установить новое соединение и повторить идемпотентный запрос. Он знает, что повторение запроса будет иметь тот же предполагаемый эффект, даже если исходный запрос был выполнен успешно, хотя ответ может отличаться.
Документация по API - это справочный документ, в котором описывается, как использовать API. Это техническое руководство, которое содержит информацию об услугах, которые предлагает API, о том, как использовать его различные конечные точки и параметры, а также другие инструкции по реализации. Документ API является частью процесса управления API. Хорошая политика документации API также помогает в управлении API.
Язык моделирования RESTful API ( RAML ) - это язык на основе YAML для описания RESTful API . Он предоставляет всю информацию, необходимую для описания RESTful или практически RESTful API. Хотя RAML разработан с учетом API-интерфейсов RESTful, он может описывать API-интерфейсы, которые не подчиняются всем ограничениям REST. Он поощряет повторное использование, делает возможным обнаружение и совместное использование шаблонов и нацелен на появление передовых практик, основанных на заслугах.
OpenAPI (Swagger)
OpenAPI - это стандарт для описания API-интерфейсов REST, который позволяет объявлять метод безопасности API, конечные точки, данные запроса / ответа и сообщения о состоянии HTTP.
Анатомия документа OpenAPI
В документе OpenAPI есть три обязательных раздела или объекта:
- openapi - семантический номер версии спецификации OpenAPI.
- info - метаданные об API
- paths - доступные пути и операции для API
При необходимости можно добавить дополнительные объекты. Другие объекты включают безопасность, серверы, теги и компоненты.
OpenAPI и информационные объекты
В объекте openapi указывается версия спецификации, используемая для документа. Версия позволяет понять, как структурирован документ, и, что более важно, для любых инструментов, которые могут принимать документ в целях проверки или для создания виртуальных сервисов, среди прочего. Информация объект содержит основную информацию о самом API. Заголовок и версия являются обязательными полями, и есть возможность включить дополнительную информацию, такую как описание, контактную информацию и информацию о лицензии
Объект Paths
Объект paths - это сердце документа API. Этот объект детализирует доступные пути для взаимодействия с приложением, какие методы доступны и детали того, что включают эти взаимодействия. Этот объект включает параметры запроса и ожидаемые результаты. Вышеприведенный отрывок описывает путь для запроса GET для получения пользовательских предпочтений по идентификатору.
Свойство $ ref
Следует отметить схему ответа HTTP 200. Свойство $ ref ссылается на объект в другом месте файла. В данном случае это описание схемы, которое используется для описаний нескольких путей. Определение компонентов в одном месте и ссылки на те объекты, которые его используют, позволяют повторно использовать одно и то же определение и сделать контракт OpenAPI более управляемым.
- Защищенный HTTPS API без какой-либо аутентификации
- Не реализовано ограничение скорости или дросселирование
- Незащищенная личность и ключи
- Слабые API-ключи
Аспекты безопасности с учётом рекомендаций REST
-
Системы RESTful не должны иметь состояния. REST определяет сервер как не имеющий состояния, а это означает, что сохранение пользовательских данных в сеансе после первоначального входа в систему не является хорошей идеей.
-
Необходимо использовать HTTPS. В системах RESTful на основе HTTP следует использовать HTTPS для обеспечения шифрования канала, что затрудняет захват и чтение трафика данных (атака «человек посередине»).
64. Методы аутентификации с сохранением состояния и без сохранения состояния в архитектуре REST. Примеры.
Методы аутентификации без сохранения состояния.
Если нужно использовать аутентификацию без сохранения состояния, необходимо включить ее в свои запросы. Чтобы гарантировать подлинность каждого запроса, можно заимствовать этап подписи OAuth 1.0a и применять его к каждому запросу, используя предварительно установленный секретный ключ между клиентом и сервером и MAC (код аутентификации сообщения) алгоритм подписи
MAC (код аутентификации сообщения)
Поскольку механизм без сохраняения состояния, информация, необходимая для генерации MAC, также должна быть отправлена как часть запроса, чтобы сервер мог воссоздать результат и подтвердить его достоверность. Этот подход имеет ряд явных преимуществ, в основном:
- Это проще, чем OAuth 1.0a и OAuth 2.0.
- Требуется нулевое хранилище, так как вся необходимая информация для проверки шифрования должна отправляться по каждому запросу
Методы аутентификации с сохранением состояния
OAuth 1.0a, OAuth 2.0, Digest Auth и Basic Auth + TSL - самые популярные методы аутентификации в наши дни. Они прекрасно работают, они реализованы на всех современных языках программирования.
- Базовая аутентификация с TSL
- Дайджест-аутентификация (Добавляет дополнительный уровень безопасности за счет шифрование информации для входа)
- OAuth 1.0a
Общий механизм его работы заключается в предоставлении приложению токена доступа (который представляет собой разрешение пользователя для клиента на доступ к своим данным) для аутентификации запроса
Различия между OAuth 1.0 и OAuth 2 (Существует две версии авторизации OAuth: OAuth 2.0 (он использует протокол HTTPS для передачи токенов) и OAuth 1 (он использует строки подписи HMAC-SHA))
Дайджест-аутентификация доступа — один из общепринятых методов, используемых веб-сервером для обработки учетных данных пользователя веб-браузера. Аналогичный метод используется в рамках VoIP-протокола SIP для аутентификации сервером обращения со стороны клиента, т.е. оконечного терминала. Данный метод отправляет по сети хеш-сумму логина, пароля, адреса сервера и случайных данных, и предоставляет больший уровень защиты, чем базовая аутентификация, при которой данные отправляются в открытом виде.
Технически, аутентификация по дайджесту представляет собой применение криптографической хеш-функции MD5 к секрету пользователя с использованием случайных значений для затруднения криптоанализа и предотвращения replay-атак. Работает на уровне протокола HTTP.
Добавляет дополнительный уровень безопасности за счет шифрование информации для входа. Определена RFC 2069 и RFC 2617. Алгоритм не устойчив к коллизиям, что в основном означает, что атака «человек посередине» позволит злоумышленнику получить необходимую информацию и сгенерировать набор действительных учетных данных. Возможным улучшением этого метода, как и его «базового» брата, было бы добавление TSL; это определенно поможет сделать его более безопасным
Общий механизм его работы заключается в предоставлении приложению токена доступа (который представляет собой разрешение пользователя для клиента на доступ к своим данным) для аутентификации запроса.
OAuth 1 имеет несколько взаимодействующих компонентов:
- Пользователь - это человек, который хочет получить доступ.
- Потребитель - это приложение или веб-сайт, которые используют OAuth для доступа к поставщику услуг.
- Поставщик услуг - это веб-приложение, которое обеспечивает доступ через OAuth.
- Защищенный ресурс - это данные, к которым пользователь хочет получить доступ
Поставщик услуг должен разрешить разработчику клиентского приложения зарегистрировать приложение на веб-сайте поставщика. Разработчик получает ключ(key) (уникальный идентификационный ключ для своей приложение) и secret.
Выполняются следующие шаги:
- Клиентскому приложению требуется токен запроса. Чтобы получить токен запроса, сервер должен предоставить конкретный URL-адрес.
- После получения токена запроса клиент должен сделать запрос, используя токен на определенном URL-адресе сервера, чтобы получить авторизацию от конечного пользователя.
- После авторизации пользователя клиентское приложение запрашивает у провайдера токен доступа и секретный ключ токена.
- После получения токена доступа и секретного токена клиентское приложение может запрашивать защищенные ресурсы для поставщика от имени пользователя, подписывая каждый запрос.
Различия между OAuth 1.0 и OAuth 2
Существует две версии авторизации OAuth: OAuth 2.0 (он использует протокол HTTPS для передачи токенов) и OAuth 1 (он использует строки подписи HMAC-SHA).
Основная проблема с реализациями систем, которые работали с OAuth 1.0, заключалась в сложности, связана с подписанием каждого запроса. Последний шаг является ключевым слабым местом алгоритма: если клиент или сервер допустят крошечную ошибку, запросы не будут проверяться. OAuth 2.0 пытается упростить последний шаг, внося некоторые ключевые изменения, в основном:
- Он полагается на SSL (или TSL), чтобы гарантировать, что информация, отправляемая туда и обратно, зашифрована.
- Подписи не требуются для запросов после того, как токен был сгенерирован.
67. Методы аутентификации с сохранением состояния в архитектуре REST. OAuth 2.0. Различия между OAuth 1.0 и OAuth 2.
OAuth 2.0 — протокол авторизации, позволяющий выдать одному сервису (приложению) права на доступ к ресурсам пользователя на другом сервисе. Протокол избавляет от необходимости доверять приложению логин и пароль, а также позволяет выдавать ограниченный набор прав, а не все сразу.
Как и первая версия, OAuth 2.0 основан на использовании базовых веб-технологий: HTTP-запросах, редиректах и т. п. Поэтому использование OAuth возможно на любой платформе с доступом к интернету и браузеру: на сайтах, в мобильных и desktop-приложениях, плагинах для браузеров…
Ключевое отличие от OAuth 1.0 — простота. В новой версии нет громоздких схем подписи, сокращено количество запросов, необходимых для авторизации.
Общая схема работы приложения, использующего OAuth, такова: получение авторизации обращение к защищенным ресурсам
Результатом авторизации является access token — некий ключ (обычно просто набор символов), предъявление которого является пропуском к защищенным ресурсам. Обращение к ним в самом простом случае происходит по HTTPS с указанием в заголовках или в качестве одного из параметров полученного access token'а.
В протоколе описано несколько вариантов авторизации, подходящих для различных ситуаций: авторизация для приложений, имеющих серверную часть (чаще всего, это сайты и веб-приложения) авторизация для полностью клиентских приложений (мобильные и desktop-приложения) авторизация по логину и паролю восстановление предыдущей авторизации
Авторизация для приложений, имеющих серверную часть
- Редирект на страницу авторизации
- На странице авторизации у пользователя запрашивается подтверждение выдачи прав
- В случае согласия пользователя, браузер редиректится на URL, указанный при открытии страницы авторизации, с добавлением в GET-параметры специального ключа — authorization code
- Сервер приложения выполняет POST-запрос с полученным authorization code в качестве параметра. В результате этого запроса возвращается access token
68. Методы аутентификации без сохранения состояния. Примеры алгоритмов. Алгоритм MAC (Message Authentication Code)
Методы аутентификации без сохранения состояния. Алгоритм MAC (Message Authentication Code)
Если нужно использовать аутентификацию без сохранения состояния, необходимо включить ее в свои запросы. Чтобы гарантировать подлинность каждого запроса, можно заимствовать этап подписи OAuth 1.0a и применять его к каждому запросу, используя предварительно установленный секретный ключ между клиентом и сервером и MAC (код аутентификации сообщения) алгоритм подписи.
MAC (код аутентификации сообщения)
Поскольку механизм без сохранения состояния, информация, необходимая для генерации MAC, также должна быть отправлена как часть запроса, чтобы сервер мог воссоздать результат и подтвердить его достоверность. Этот подход имеет ряд явных преимуществ, в основном:
- Это проще, чем OAuth 1.0a и OAuth 2.0.
- Требуется нулевое хранилище, так как вся необходимая информация для проверки шифрования должна отправляться по каждому запросу.
69. Методы аутентификации без сохранения состояния. Имитовставка. Алгоритм MAC(Message Authentication Code) и HMAC (hash-based message authentication code).
MAC
Имитовста́вка (MAC, англ. message authentication code — код аутентификации послания) — средство обеспечения имитозащиты в протоколах аутентификации сообщений с доверяющими друг другу участниками — специальный набор символов, который добавляется к сообщению и предназначен для обеспечения его целостности и аутентификации источника данных.
Имитовставка обычно применяется для обеспечения целостности и защиты от фальсификации передаваемой информации.
Для проверки целостности (но не аутентичности) сообщения на отправляющей стороне к сообщению добавляется значение хеш-функции от этого сообщения, на приёмной стороне также вырабатывается хеш от полученного сообщения. Выработанный на приёмной стороне и полученный хеш сравниваются. В случае равенства считается, что полученное сообщение дошло без изменений.
Для защиты от фальсификации (имитации) сообщения применяется имитовставка, выработанная с использованием секретного элемента (ключа), известного только отправителю и получателю.
HMAC
HMAC (иногда расшифровывается как англ. hash-based message authentication code, код аутентификации (проверки подлинности) сообщений, использующий хеш-функции, или как англ. keyed-hash message authentication code, код аутентификации сообщений, использующий хеш-функции с ключом) — в информатике (криптографии), один из механизмов проверки целостности информации, позволяющий гарантировать то, что данные, передаваемые или хранящиеся в ненадёжной среде, не были изменены посторонними лицами (см. человек посередине). Механизм HMAC использует имитовставку (MAC), описан в RFC 2104, в стандартах организаций ANSI, IETF, ISO и NIST. MAC — стандарт, описывающий способ обмена данными и способ проверки целостности передаваемых данных с использованием секретного ключа. Два клиента, использующие MAC, как правило, используют общий секретный ключ. HMAC — надстройка над MAC; механизм обмена данными с использованием секретного ключа (как в MAC) и хеш-функций. В названии может уточняться используемая хеш-функция[1]: HMAC-MD5, HMAC-SHA1, HMAC-RIPEMD128, HMAC-RIPEMD160 и т. п.
70. Что понимается под гибридными архитектурами интерфейсов прикладного программирования? Приведите примеры распространённых гибридных архитектур.
Примерами гибридных систем является API Amazon E-Commerce Service, Flickr, YAHOO и т.д. Обычно представляют собой гибриды REST-RPC. Обычно они работают как REST(с гипермедиа), когда вы получаете данные, но они представляют собой службы в стиле RPC, когда приходит время изменять данные.
Каждый запрос веб-службы включает одни и те же три шага:
- Придумайте данные, которые войдут в HTTP-запрос: метод HTTP, URI, любые заголовки HTTP и (для запросов, использующих метод PUT или POST) любой документ, который должен быть помещен в тело объекта запроса.
- Отформатируйте данные как HTTP-запрос и отправьте его на соответствующий HTTP-сервер.
- Разберите данные ответа - код ответа, любые заголовки и любое тело объекта - в структуры данных, необходимые для остальной части вашей программы.
71. Базовая внутренняя архитектура RESTful API. Какие компоненты могут входить в базовую архитектуру RESTful API?
Привязка к Node.js Базовая внутренняя архитектура RESTful API содержит следующие элементы:
- Обработчик запросов. Это механизм, который получает каждый запрос и обрабатывает его, прежде чем делать что-либо еще.
- Цепочка промежуточного программного обеспечения / предварительной обработки. Помогают сформировать запрос и помогают контролировать аутентификацию.
- Обработчик маршрутов. После того, как обработчик запроса выполнен, а сам запрос был проверен и дополнен всем необходимым, этот компонент определяет, кто должен позаботиться о запросе.
- Контроллер. Отвечает за все запросы, относящиеся к одному конкретному ресурсу.
- Модель . В нашем случае также называется ресурсом. Здесь вы сосредоточите большую часть логики, связанной с ресурсом.
- Уровень представления. Этот уровень заботится о создании представления, видимого клиентскому приложению.
- Обработчик ответа. Заботится об отправке представления ответа обратно клиенту.
Паттерн MVC (модель – представление – контроллер)
Причина, по которой это такой популярный шаблон в веб-проектах, заключается в том, что он идеально вписывается в многоуровневую архитектуру, которую предоставляет Интернет.
Показано разделение трех компонентов: контроллера, модели (которую в этом случае также можно вызвать ресурсом) и представления. Такое разделение позволяет четко определить обязанности каждого компонента, что, в свою очередь, помогает сохранять код чистым и легким для понимания.
Современная модернизированная версия MVC
Текущая версия шаблона удалила связь между моделью и представлением и вместо этого возложила эту ответственность на контроллер. Контроллер теперь также управляет представлением.
В архитектуру добавлены шаги 5 и 6. Когда запускается правильный метод на контроллере (на шаге 4), он обрабатывает взаимодействие с моделью, собирает необходимые данные, а затем отправляет их в представление, чтобы отобразить их обратно в клиентское приложение. Эта архитектура отлично работает, но есть еще одно улучшение, которое можно сделать.
Улучшенная архитектура REST API с добавленным шаблоном MVC
В предыдущей архитектуре представления строго связаны со структурой данных ресурсов, и можно обобщить представление до уровня представления, который позаботится о преобразовании ресурсов в любой требуемый формат. Это изменение упрощает разработку, поскольку централизуется весь связанный с представлением код в одном компоненте (уровне представления). Изменение окна представления на уровень представления представляет собой обобщение этого кода, что первоначально предполагало, что будет один конкретный код представления для каждого ресурса.
73. Шаблоны проектирования и их использование при разработке API. Шаблон Иерархический MVC (HMVC). Пример использования.
Иерархический MVC (HMVC)
Иерархический MVC - это более сложная версия MVC в том смысле, что она позволяет вкладывать один компонент MVC в другой. Это дает разработчикам возможность иметь такие вещи, как группа MVC для страницы, другая группа MVC для навигации внутри страницы и последний компонент MVC для содержимого страницы.
Пользователь читает сообщение в блоге и соответствующие комментарии под ним. Это можно сделать двумя способами: с помощью MVC или HMVC. В MVC запрос выполняется к контроллеру BlogPosts, поскольку это основной запрашиваемый ресурс; после этого этот контроллер загружает соответствующую модель сообщения в блоге и, используя идентификатор этой модели, загружает связанные модели комментариев. Здесь возникает нежелательная связь между контроллером BlogPosts и моделью комментариев.
Теперь, на шаге 3, отправляется запрос совершенно новому компоненту MVC, отвечающему за работу с комментариями. Этот компонент, в свою очередь, будет взаимодействовать с соответствующей моделью и с общим слоем представления, чтобы вернуть представление комментариев.
Какие преимущества? Если необходимо создать новый раздел в блоге, показывающий определенные сообщения в блоге и их комментарии, вы можете легко повторно использовать компонент комментариев.
74. Шаблоны проектирования и их использование при разработке API. Модель – Представление – Модель представления (Model–View–ViewModel).
Модель – Представление – Модель представления (Model–View–ViewModel)
Частое применение - позволяет разработчикам пользовательского интерфейса писать код с использованием языка разметки (называемого XAML), ориентированного на взаимодействие с пользователем (UX) и доступа к динамическим функциям с помощью привязок к коду. модель в этой архитектуре концентрирует бизнес-логику, в то время как ViewModel действует как посредник между моделью и представлением, предоставляя данные из первого. Содержит большую часть логики представления, позволяя ViewLayer сосредоточиться только на отображении информации, оставляя все динамические поведение ViewModel.
Full-Stack. Например, набирает популярность технологический стэк MEAN (MongoDB , Express.js, Angular.js и Node.js) или, например, MERN(MongoDB, Express.js, React и Node.js).
MEAN (MongoDB , Express.js, Angular.js и Node.js)
Лучший способ создания API-интерфейсов и управления ими с использованием схем, описаний и руководств по стилю.
- Спецификация - это технический документ, в котором рассказывается, как что-то работает.
2 Подхода к проектированию и разработке API:
- Проектируем и реализуем конечные точки
- Описываем API через спецификацию, далее на основе спецификации реализуется программный интерфейс
С момента появления API были разработаны различные форматы спецификаций, чтобы стандартизировать то, как мы их описываем.
- Язык описания веб-сервисов ( WSDL ) был создан Ariba, IBM и Microsoft как машиночитаемый способ описания сервисов в 2001 году.
- Язык описания веб-приложений ( WADL ) был разработан Sun Microsystems как RESTful-эквивалент WSDL в 2009 году.
- Swagger был проектом 2011 года, приобретенным SmartBear, затем переданный Linux Foundation Open API Initiative, который в конечном итоге был переименован в OpenAPI Specification.
- Язык моделирования RESTful API ( RAML ) был разработан MuleSoft и группой других корпоративных компаний в 2013 году, чтобы сосредоточиться на дизайне API.
- OpenAPI Specification ( OAS ) в настоящее время является лидером на рынке форматов спецификаций и поддерживается рядом крупных предприятий.
- Есть и другие, например, конечные точки Google Cloud, Протокол открытых данных (OData), Язык описания служб RESTful (RSDL), apiblueprint, apibuilder.io, Apache Avro, Словарь Hydra Core и т.д.
Спецификация OpenAPI (Swagger)
OpenAPI - это стандарт для описания API-интерфейсов REST, который позволяет объявлять метод безопасности API, конечные точки, данные запроса / ответа и сообщения о состоянии HTTP.
В документе OpenAPI есть три обязательных раздела или объекта:
- openapi - семантический номер версии спецификации OpenAPI.
- info - метаданные об API
- paths - доступные пути и операции для API.
При необходимости можно добавить дополнительные объекты. Другие объекты включают безопасность, серверы, теги и компоненты.
В объекте openapi указывается версия спецификации, используемая для документа. Версия позволяет понять, как структурирован документ, и, что более важно, для любых инструментов, которые могут принимать документ в целях проверки или для создания виртуальных сервисов, среди прочего. Информация объект содержит основную информацию о самом API. Заголовок и версия являются обязательными полями, и есть возможность включить дополнительную информацию, такую как описание, контактную информацию и информацию о лицензии.
Объект paths - это сердце документа API. Этот объект детализирует доступные пути для взаимодействия с приложением, какие методы доступны и детали того, что включают эти взаимодействия. Этот объект включает параметры запроса и ожидаемые результаты. Вышеприведенный отрывок описывает путь для запроса GET для получения пользовательских предпочтений по идентификатору.
Следует отметить схему ответа HTTP 200. Свойство $ ref ссылается на объект в другом месте файла. В данном случае это описание схемы, которое используется для описаний нескольких путей. Определение компонентов в одном месте и ссылки на те объекты, которые его используют, позволяют повторно использовать одно и то же определение и сделать контракт OpenAPI более управляемым.
RESTful API ( RAML )
Язык моделирования RESTful API ( RAML ) - это язык на основе YAML для описания RESTful API .
Он предоставляет всю информацию, необходимую для описания RESTful или практически RESTful API. Хотя RAML разработан с учетом API-интерфейсов RESTful, он может описывать API-интерфейсы, которые не подчиняются всем ограничениям REST. Он поощряет повторное использование, делает возможным обнаружение и совместное использование шаблонов и нацелен на появление передовых практик, основанных на заслугах.
- SoapUI
SoapUI представляет собой консольный инструмент, предназначенный для тестирования API и позволяющий пользователям легко тестировать API REST и SOAP, а также Web-сервисы.
При помощи SoapUI, пользователи могут получить полный исходный документ и встроить предпочтительный набор функций, в дополнение к перечисленным ниже:
Создать тест легко и быстро при помощи технологий перетаскивания объектов «мышкой» (Drag and drop) и метода «указания и щелчка» (Point-and-click) Быстро создать пользовательский код при помощи Groovy Мощное тестирование на основе данных: Данные загружаются из файлов, баз данных и Excel, поэтому они могут создать симуляцию взаимодействия пользователя и API. Создание комплексных сценариев и поддержка асинхронного тестирования Повторное использование скриптов: загрузка тестов и сканирование безопасности могут повторно использоваться в случае функционального тестирования всего в несколько шагов
- Postman
Будучи изначально плагином браузера Chrome, теперь Postman расширяет свои технические решения вместе с оригинальными версиями как для Mac, так и для Windows.
Postman является отличным выбором API тестирования для тех, кто не желает иметь дела с кодировками в интегрированной среде разработки, используя тот же язык программирования, что и разработчик.
Легкий в использовании клиент REST Богатый интерфейс делает этот инструмент простым и удобным в использовании Может использоваться как при автоматическом, так и при исследовательском тестировании Работает в приложениях для Mac, Windows, Linux и Chrome Обладает пакетом средств интеграции, таких как поддержка форматов Swagger и RAML Обладает функциями Run, Test, Document и Monitoring Не требует изучения нового языка программирования Позволяет пользователям легко делиться опытом и знаниями с другими членами команды, поскольку позволяет упаковывать все запросы и ожидаемые ответы и отправлять их коллегам.
- Katalon Studio
Katalon Studio является бесплатным инструментом автоматического тестирования, предоставляющим общую среду для создания и выполнения UI функционала, служб API/Web и тестирования мобильных платформ.
Способность комбинировать уровни UI и Business (службы API/Web) для различных операционных сред (Windows, Mac OS, Linux) расценивается как значительное преимущество Katalon Studio перед аналогичными продуктами.
Katalon Studio поддерживает запросы SOAP и RESTful с различными типами команд (GET, POST, PUT, DELETE) с параметризованными возможностями. Основные свойства:
Поддержка теста комбинации между верификациями UI и API. Поддержка тестирования запросов как SOAP, так и RESTful. Сотни встроенных ключей для создания тестовых заданий. Поддержка одной из самых мощных библиотеки проверки утверждений AssertJ для создания динамических утверждений в BDD-стиле. Поддержка подхода, управляемого данными. Может использоваться как при автоматическом, так и при исследовательском тестировании. Отлично подходит как для профессионалов, так и для новичков
GraphQL - это язык запросов и среда выполнения на стороне сервера для интерфейсов прикладного программирования (API), которая отдает приоритет предоставлению клиентам именно тех данных, которые они запрашивают, и не более того. Слово граф в GraphQL происходит от того факта, что лучший способ представления данных в реальном мире - это структура данных, подобная графу.
Со временем появились различные архитектурные стили API. Каждый из них содержит собственные схемы стандартизации обмена данными. Наличие выбора вызывает бесконечные споры о том, какой архитектурный стиль лучше.
Сравнение REST и GraphQL
- Сходство: есть понятие ресурса, есть возможность назначать идентификаторы для ресурсов.
- Сходство: ресурсы могут быть извлечены с помощью GET-запроса URL-адреса по HTTP.
- Сходство: ответ на запрос может возвращать данные в формате JSON.
- Различие: в REST вызываемая вами конечная точка (endpoint) — это и есть сущность объекта. В GraphQL сущность объекта отделена от того, как именно вы его получаете.
- Различие: в REST структура и объем ресурса определяются сервером. В GraphQL сервер определяет набор доступных ресурсов, а клиент указывает необходимые ему данные прямо в запросе.
GraphQL - это язык и среда выполнения
Клиент отправляет этот текстовый запрос службе API через транспортный канал (например, HTTPS). Уровень выполнения GraphQL принимает текстовый запрос, взаимодействует с другими службами в бэкэнд-стеке, чтобы собрать подходящий ответ данных, а затем отправляет эти данные обратно потребителю в формате, подобном JSON.
GraphQL начинается с построения схемы, которая представляет собой описание всех запросов, которые возможно сделать в API GraphQL, и всех типов данных, которые они возвращают. Используется строгая типизация на языке определения схемы (Schema Definition Language, SDL).
Клиент, который располагает схемой перед отправкой запроса, может проверить свой запрос и убедиться, что сервер сможет ответить на него. Добравшись до бэкэнда, операция GraphQL интерпретируется по всей схеме и разрешается с помощью данных для фронтэнда. Отправив один массивный запрос на сервер, API возвращает ответ в формате JSON с точно теми данными, которые мы запросили.
gRPC (Remote Procedure Calls) — это система удалённого вызова процедур (RPC) с открытым исходным кодом, первоначально разработанная в Google в 2015 году. В качестве транспорта используется HTTP/2, в качестве языка описания интерфейса — Protocol Buffers. gRPC предоставляет такие функции как аутентификация, двунаправленная потоковая передача и управление потоком, блокирующие или неблокирующие привязки, а также отмена и тайм-ауты. Генерирует кроссплатформенные привязки клиента и сервера для многих языков. Чаще всего используется для подключения служб в микросервисном стиле архитектуры и подключения мобильных устройств и браузерных клиентов к серверным службам.
Сложное использование HTTP/2 в gRPC делает невозможным реализацию клиента gRPC в браузере - вместо этого требуется прокси.
В gRPC клиентское приложение может напрямую вызывать метод серверного приложения на другом компьютере, как если бы это был локальный объект, что упрощает создание распределенных приложений и служб. Как и во многих системах RPC, gRPC основан на идее определения службы, определяя методы, которые могут быть вызваны удаленно с их параметрами и типами возвращаемых данных. На стороне сервера сервер реализует этот интерфейс и запускает сервер gRPC для обработки клиентских вызовов. На стороне клиента есть заглушка (называемая на некоторых языках просто клиентом), которая предоставляет те же методы, что и сервер.
Клиенты и серверы gRPC могут работать и взаимодействовать друг с другом в различных средах и могут быть написаны на любом из поддерживаемых языков gRPC.