CC BY
116СРАВНИТЕЛЬНЫЙ АНАЛИЗ ПОДХОДОВ В РАЗРАБОТКЕ API ВЕБ-
ПРИЛОЖЕНИЙ
COMPARISON OF WEB APPLICATION API DEVELOPMENT
APPROACHES
УДК 004
Шор Александр Михайлович
Магистрант направления подготовки 11.04.02 «Инфокоммуникационные технологии и системы связи» ФГАОУ ВО «Национальный исследовательский университет ИТМО», Россия, Санкт-Петербург Научный руководитель: Грудинин Владимир Алексеевич, доцент ФИКТ, кандитат технических наук, ФГАОУ ВО «Национальный исследовательский университет ИТМО», Россия, Санкт-Петербург Aleksandr Shor
Student of Saint-Petersburg National Research University of Information Technologies, Mechanics and Optics, 11.04.02 «Infocommunication technologies and communication systems», Russia, Saint-Petersburg E-mail: [email protected]
Scientific adviser: Vladimir Grudinin, docent, PhD in Engineering sciences, Saint-Petersburg National Research University of Information Technologies, Mechanics and Optics, Russia, Saint-Petersburg
АННОТАЦИЯ
В настоящее время интернет очень плотно проник в нашу жизнь, и бизнес нуждается в новых сайтах и веб-приложениях. Для разработчиков всё острее встает проблема выбора подхода в разработке API веб-приложений. В статье производится обзор и сравнительный анализ текущих популярных подходов: REST, SOAP и GraphQL. Для каждого подхода указана краткая справка о способах его применения. После обзора выделены преимущества и недостатки рассматриваемых подходов, указанные в таблице сравнения. В результате обзора и анализа сделан вывод, что выбор подхода в разработке API веб-приложений зависит в первую очередь от конкретной задачи.
ANNOTATION
Currently, the Internet is very tightly penetrated into our lives, and business needs new sites and web applications. For developers, the problem of choosing an approach to developing web application APIs is becoming ever more acute. The article provides a review and comparative analysis of current popular approaches: REST, SOAP, and GraphQL. For each approach, a brief reference is given on how
to use it. After the review, the advantages and disadvantages of the considered approaches are indicated in the comparison table. As a result of the review and analysis, it was concluded that the choice of approach in the development of web application APIs depends primarily on a specific task.
Ключевые слова: веб-приложения, подходы к разработке, API, REST, SOAP, GraphQL
Keywords: web applications, development approaches, API, REST, SOAP, GraphQL
На текущий момент существует три популярных подхода в разработке API веб-приложений: REST, SOAP и GraphQL. Поэтому перед каждым разработчиком API встают вопросы: какой подход лучше подойдет для моей задачи? использование какого упростит разработку и поддержку? Однозначного ответа на эти вопросы нет, ведь у каждого подхода есть как преимущества, так и недостатки. Целью данной работы является краткий обзор популярных архитектур API и их сравнение. Её прочтение должно помочь вам в предстоящем выборе.
Для начала стоит сказать, что REST («Representational State Transfer» -передача состояния представления) является не протоколом, а архитектурным стилем, поэтому не существует единого стандарта его использования. Данный термин был введен Роем Филдингом в 2000 году [1]. На текущий момент этот стиль чаще всего используется для «общения» клиента с сервером по протоколу HTTP.
Запросы клиента на сервер совершаются с использованием HTTP-методов, самые популярные из них - GET, POST, PUT и DELETE. Также часто для указания дополнительной информации используются HTTP-заголовки и параметры запросов. Иногда разработчики ограничиваются поддержкой только двух методов запросов - GET и POST. Это связано с тем, что HTML-формы поддерживают только их [2].
Допустим у сервера есть некоторые ресурсы - данные о пользователях приложения, и API доступно по адресу «/api/». Клиенту необходимо получить данные о пользователе с идентификатором «11». В REST такой запрос может выглядеть следующим образом: «GET /api/users/11». Для внесения нового пользователя с автоматически сгенерированным идентификатором может использоваться запрос «POST /api/users/», причем данные о пользователе могут передаваться в любом формате. Для обновления текущего пользователя - «PUT /api/users/11», а для удаления - «DELETE /api/users/11». Все параметры запроса обычно указываются стандартно по протоколу HTTP.
Для ответов используют тело ответа и HTTP-коды, которых существует большое количество. Они помогают в определении смысла ответов. Ниже перечислены наиболее популярные коды [3]:
• 200 - ОК - успешный запрос
• 401 - Unauthorized - аутентификация не пройдена
• 400 - Bad request - неверный запрос
• 404 - Not found - ресурс не найден
• 500 - Internal Server Error - внутренняя ошибка сервера
SOAP (Simple Object Access Protocol) - простой протокол доступа к объектам [4]. В отличии от REST является протоколом и стандартизован Консорциумом Всемирной паутины (W3C). Может использоваться с любым протоколом прикладного уровня, но чаще всего используется вместе с HTTP.
В рамках API веб-приложения в теле как запроса, так и ответа по протоколу HTTP передается XML. Автоматическая валидация и строгая типизация данных осуществляется с помощью языка «XML Schema». С помощью схемы изначально определяется формат сообщения. У сервера веб-приложения в случае данного подхода есть только один вход, а сервер вызывает процедуру, интерпретируя полученные данные. Пакеты, передаваемые между клиентом и сервером, называют SOAP-конвертами. В структуре конверта основной раздел Envelop, который включает в себя либо Header и Body, либо Fault в случае ошибки [5].
Вместе с SOAP используют WSDL - язык, основанный на XML и созданный для описания работы веб-приложений. С помощью файла в данном формате описывается вся техническая информация для взаимодействия клиента с сервером: типы данных, элементы данных, список операций и способ доставки сообщения. Таким образом, клиенту для начала работы с API сервера необходим данный файл.
Допустим, необходимо получить информацию о пользователе с идентификатором 11 и есть токен доступа к API, который выступает в роли временного пароля. Пример такого SOAP запроса представлен на рисунке 1.
< s о ар env :Env elop е xmlns: s о ар eav="http ://s che-
xnilns :xsd="http ://www.w3. or g/2001 /XMLScliema" xmlns :x s i= "http ://www. w3.org/2001 /XMLS chema - inst ance'f >
<token>alb4dd3cd2777b3S3bdb048ccSe4bf40</token>
Рисунок 1 - Пример SOAP запроса В ответ сервер отправит информацию о пользователе и номер запроса (Рисунок 2).
<soap env :Env elope xmlns :sQapenv=,rhttp ://sche-
xmlns:xsd="http ://www.w3. org/2001 /XMLS chema" xmlas :xsi=,fhttp ://www. w3. org/2001 /XMLS chema-iinstance">
<requestld>808b99al73b0c377049acb73al7badl0</requestld> Рисунок 2 - Пример ответа сервера на SOAP запрос
GraphQL - язык запросов данных для API с открытым кодом, созданный в Facebook, который использует его в своих проектах с 2012 года. GraphQL стандартизован и имеет подробную спецификацию.
Язык создавался как альтернатива REST и с целью уменьшить количество запросов для представления данных. API, спроектированное таким образом, имеет одну точку входа и позволяет получить данные, которые предоставляет сервер, в формате JSON с любой вложенностью и в необходимом количестве. То есть сервер может отдать свои ресурсы, как это удобнее клиенту, и нет необходимости создавать обработку множества запросов для разных данных с целью поддержки универсальности для клиентов.
При разработке API сначала описывается схема данных - объекты и их строго типизированные поля, которыми оперирует сервер [6]. Далее описываются распознаватели - функции, через которые можно получить доступ к этим объектам. Ограничения по безопасности можно ставить на уровне распознавателей.
После этого со стороны клиента на сервер можно отправлять запросы. Синтаксис запросов GraphQL довольно богат и поддерживает следующую функциональность [6]:
• аргументы полей
• переменные, директивы и фрагменты для создания динамических запросов
• аллиасы для смены имён полей в ответе сервера
• именные запросы для избегания дублирования кода
• получение метаданных сервера, например, типов полей или схемы данных
К примеру, необходимо получить с сервера, поддерживающего GraphQL, информацию о пользователях приложения. Тогда запрос и ответ на него могут выглядеть так, как представлено на рисунке 3.
Запрос
Ответ
user (id: "11") {
"data": { "user": {
id,
firstName, lastName
"id": 11,
"firstName": "Ivau", "lastName": "Ivanov
}
}
}
}
}
Рисунок 3 - Пример GraphQL запроса и ответа
Как уже говорилось ранее, у каждого из подходов есть как преимущества, так и недостатки, которые выявляются, как и при их изучении, так и при практической реализации. Сравнение подходов представлено в таблице 1. Таблица 1 - Сравнение подходов в разработке API веб-приложений
Подходы
Преимущества
Недостатки
REST
1. Простота реализации. Для использования архитектуры REST в веб-приложении обычно не требуется дополнительных решений, потому что клиент и сервер по умолчанию поддерживают HTTP-запросы.
2. Существует большое количество инструментов и библиотек для разработчиков, которые могут упростить разработку и отладку, но их наличие не является обязательным для нормальной разработки.
3. В ответе сервера, как и в запросе клиента, данные могут быть представлены в разных форматах в рамках одного приложения.
1. Сложность поддержки. Как говорилось ранее, не существует единого стандарта для REST, поэтому практические реализации очень сильно разнятся.
2. Количество HTTP-методов, поддерживаемых по умолчанию различными серверами и клиентами, может отличаться. Поэтому разработчик зачастую ограничен использованием только самых популярных.
SOAP
1. Полностью стандартизован, что упрощает поддержку.
2. Использует XML со строгой типизацией данных, что гарантирует их целостность и делает возможной автоматическую валидацию.
3. Возможно автоматизировать генерацию XML при помощи схем.
1. Ответ сервера, как и запрос клиента, может быть представлен только в формате XML.
2. Протокол сложен в освоении для разработчиков, поэтому с версии 1.2 аббревиатура SOAP не расшифровывается [4].
3. Сложность протокола несет собой потерю в производительности.
4. На практике при создании API с помощью SOAP может потребоваться установка дополнительных библиотек и инструментов для редактирования XML-схем.
GraphQL 1. Большая гибкость запросов. Клиент запрашивает с сервера то, что действительно необходимо и с такой вложенностью, с какой пожелает. 2. Возможность на уровне спецификации генерировать динамические запросы и переиспользовать их код. 3. Полностью стандартизован язык с подробной спецификацией, что упрощает поддержку. 4. Постепенно возрастает выбор библиотек и инструментов разработки. 1. За счет гибкости обработки запросов сервером снижается производительность. 2. Язык достаточно новый, поэтому нет такого большого выбора библиотек и инструментов, как в случае с REST или SOAP, без которых быстрое развертывание и тестирование GraphQL-сервера является проблематичным. 3. Ответ сервера и запрос клиента может использовать для данных только JSON.
В данной работе был осуществлен обзор трех популярных подходов в разработке API веб-приложений. Далее были приведены их преимущества и недостатки в виде таблицы. Выбор подхода зависит в первую очередь от задачи и остается за читателем. Для простых приложений, на взгляд автора, лучше подходит REST. Если существует несколько представлений одних данных и нет высоких требований к производительности, то хорошо подойдет GraphQL. Для Enterprise-приложений, в которых часто используется XML, хорошо зарекомендовал себя SOAP.
Литература
1. Roy Fielding. Architectural Styles and the Design of Network-based Software Architectures // UNIVERSITY OF CALIFORNIA, IRVINE. 2000.
2. W3C. HTML 5.2. [Электронный ресурс]. URL: https://www. w3.org/TR/html52/ (дата обращения: 27.05.2019).
3. JazzTeam Software Development Company. Лучшие практики проектирования REST API. [Электронный ресурс]. URL:
https://j azzteam. org/ru/technical-articles/restful-services-manual/_(дата
обращения: 27.05.2019).
4. W3C. SOAP. - 2007. [Электронный ресурс]. URL: https://www. w3.org/TR/soap/ (дата обращения: 27.05.2019).
5. Васвани В. Zend Framework: разработка веб-приложений на PHP // Питер. - 2011.
6. Facebook Inc. GraphQL. - 2016. [Электронный ресурс]. URL: http: //graphql. org/learn/queries/ (дата обращения: 27.05.2019).
Literature
1. Roy Fielding. Architectural Styles and the Design of Network-based Software Architectures // UNIVERSITY OF CALIFORNIA, IRVINE. 2000.
2. W3C. HTML 5.2. [Electronic resource]. URL: https://www.w3.org/TR/html52/ (accessed: 05/27/2019).
3. JazzTeam Software Development Company. Best practices for designing a REST API. [Electronic resource]. URL: https://jazzteam.org/ru/technical-articles/restful-services-manual/ (accessed: 05.27.2019).
4. W3C. SOAP - 2007. [Electronic resource]. URL: https://www.w3.org/TR/soap/ (accessed: 05/27/2019).
5. Vaswani V. Zend Framework: development of web applications in PHP // Peter. - 2011.
6. Facebook Inc. GraphQL. - 2016. [Electronic resource]. URL: http://graphql.org/learn/queries/ (accessed: 05/27/2019).
