-
Notifications
You must be signed in to change notification settings - Fork 53
Тема 35. HTTP и REST
- Обзор протокола HTTP
- Обзор подходов построения REST API
- Форматы данных (JSON, XML, YAML)
- Список литературы/курсов
Речь пойет о протоколах передачи данных по сети на прикладном уровне модели OSI.
протокол передачи данных Так называют общепринятое соглашение, благодаря которому разработчики разных сервисов отправляют информацию в едином виде.
Например, используя Google Chrome, ты можешь получить информацию и с Facebook, и с Twitter, потому что разработчики передают ее с помощью стандартного протокола HTTP, а твой браузер умеет его обрабатывать.
Единые правила очень удобны и самим разработчикам серверных частей: существует очень много библиотек, которые могут за тебя преобразовать информацию и отправить по необходимому протоколу.
Изначально HTTP задумывался как протокол передачи HTML-страниц. Долгое время так и было, но сейчас программисты частенько передают по нему и строки, и медиафайлы. В общем, этот протокол универсальный и гибкий, и использовать его действительно просто. А как это делать — сейчас разберемся. Структура HTTP Сразу стоит отметить, что HTTP-протокол состоит только из текста. Ну а нас больше всего интересует структура, в которой расположен этот текст.
Каждое сообщение состоит из трех частей: Стартовая строка (Starting line) — определяет служебные данные. Заголовки (Headers) — описание параметров сообщения. Тело сообщения (Body) — данные сообщения. Должны отделяться от заголовков пустой строкой. По HTTP-протоколу можно отправить запрос на сервер (request) и получить ответ от сервера (response). Запросы и ответы немного отличаются параметрами. Как выглядит простой HTTP-запрос GET / HTTP/1.1 Host: javarush.ru User-Agent: firefox/5.0 (Linux; Debian 5.0.8; en-US; rv:1.8.1.7)
В стартовой строке указаны: GET — метод запроса; / — путь запроса (path); HTTP/1.1 — версия протокола передачи данных. Затем следуют заголовки: Host — хост, которому адресован запрос; User-Agent — клиент, который отправляет запрос. Тело сообщения отсутствует.
В HTTP-запросе обязательны только стартовая строка и заголовок Host.
Теперь разберем все по порядку.
HTTP-запрос должен содержать какой-то метод. Всего их девять: GET, POST, PUT, OPTIONS, HEAD, PATCH, DELETE, TRACE, CONNECT. Самые распространенные — GET и POST. Этих двух методов на первых порах будет достаточно.
GET — запрашивает контент из сервера. Поэтому у запросов с методом GET нет тела сообщения. Но при необходимости можно отправить параметры через path в таком формате:
Здесь: javarush.ru — хост, /send — путь запроса, ? — разделитель, обозначающий, что дальше следуют параметры запроса.
В конце перечисляются параметры в формате ключ=значение, разделенные амперсандом.
POST — публикует информацию на сервере. POST-запрос может передавать разную информацию: параметры в формате ключ=значение, JSON, HTML-код или даже файлы. Вся информация передается в теле сообщения.
Например:
POST /user/create/json HTTP/1.1 Accept: application/json Content-Type: application/json Content-Length: 28 Host: javarush.ru
{ "Id": 12345, "User": "John" }
Запрос отправляется по адресу javarush.ru/user/create/json, версия протокола — HTTP/1.1. Accept указывает, какой формат ответа клиент ожидает получить, Content-Type — в каком формате отправляется тело сообщения. Content-Length — количество символов в теле.
HTTP-запрос может содержать много разных заголовков. Подробнее с ними можно ознакомиться в спецификации протокола. HTTP-ответы После получения запроса, сервер его обрабатывает и отправляет ответ клиенту:
HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Content-Length: 98
<title>An Example Page</title>Hello World
Стартовая строка в респонсе содержит версию протокола (HTTP/1.1), Код статуса (200), Описание статуса (OK). В заголовках — тип и длина контента. В теле ответа — HTML-код, который браузер прорисует в HTML-страницу. Response Status Codes С телом сообщения и заголовками все ясно, а о кодах статусов стоит сказать пару слов. Response Status Codes всегда трехзначные, и первая цифра кода указывает категорию ответа: 1xx — информационный. Запрос получен, сервер готов к продолжению; 2xx — успешный. Запрос получен, понятен и обработан; 3xx — перенаправление. Следующие действия нужно выполнить для обработки запроса; 4xx — ошибка клиента. Запрос содержит ошибки или не отвечает протоколу; 5xx — ошибка сервера. Сервер не смог обработать запрос, хотя был составлен верно; Вторая и третья цифры в коде детализируют ответ.
Например: 200 OK — реквест получен и успешно обработан; 201 Created — реквест получен и успешно обработан, в результате чего создан новый ресурс или его экземпляр; 301 Moved Permanently — запрашиваемый ресурс был перемещен навсегда, и последующие запросы к нему должны происходить по новому адресу; 307 Temporary Redirect — ресурс перемещен временно. Пока к нему можно обращаться, используя автоматическую переадресацию; 403 Forbidden — запрос понятен, но нужна авторизация; 404 Not Found — сервер не нашел ресурс по этому адресу; 501 Not Implemented — сервер не поддерживает функциональность для ответа на этот запрос; 505 HTTP Version Not Supported — сервер не поддерживает указанную версию HTTP-протокола. Вдобавок к статус-коду ответа также отправляется описание статуса, благодаря которому интуитивно понятно, что значит конкретный статус. Часть 3. Протоколы HTTP/HTTPS - 2HTTP-протокол очень практичен: в нем предусмотрено большое количество хедеров, используя которые можно настроить гибкое общение между клиентом и сервером. Все хедеры запросов и ответов, методы запросов и статус-коды ответов невозможно рассмотреть в одной статье. При необходимости можешь почитать официальную спецификацию протокола, которая описывает все нюансы.
HTTP-протокол принято использовать на порту 80, поэтому когда ты видишь адрес, который заканчивается портом 80, можешь быть уверен, что к нему нужно обращаться по HTTP.
С развитием технологий и активным перемещением персональных данных в интернет пришлось задуматься о том, как обеспечить дополнительную защиту информации, которую клиент передает серверу. В результате появился протокол HTTPS.
В чем отличие между HTTPS и HTTP HTTPS синтаксически идентичен протоколу HTTP, то есть использует те же стартовые строки и заголовки. Единственные отличия — дополнительное шифрование и порт по умолчанию (443).
HTTPS шифруется между HTTP и TCP, то есть между прикладным и транспортным уровнями. Если забыл, что это такое, загляни в статью о модели OSI.
Современный стандарт шифрования — по протоколу TLS. В эту темы мы слишком углубляться не будем, но запомни, что шифрование происходит перед тем, как информация попадает на транспортный уровень. В HTTPS шифруется абсолютно вся информация, кроме хоста и порта, куда отправлен запрос.
Для перевода сервера на использование HTTPS протокола вместо HTTP, нам не нужно менять код сервера. Включение этой фичи происходит в контейнерах сервлетов, о которых мы поговорим в следующих статьях.
А на сегодня все. Впрочем, погоди. Чтобы пощупать HTTP-запросы, открой Google Chrome, нажми F12, выбери вкладку Network. Тут будут отображаться все реквесты и респонсы, отправленные/полученные твоим браузером.
REST расшифровывается как representational state transfer — «передача состояния представления» или, лучше сказать, представление данных в удобном для клиента формате. Термин “REST” был введен Роем Филдингом в 2000 г. Основная идея REST в том, что каждое обращение к сервису переводит клиентское приложение в новое состояние. По сути, REST — не протокол и не стандарт, а подход, архитектурный стиль проектирования API.
Каковы принципы REST?
Клиент-серверная архитектура — без этого REST немыслим. Любые данные — ресурс. Любой ресурс имеет ID, по которому можно получить данные. Ресурсы могут быть связаны между собой — для этого в составе ответа передается либо ID, либо, как чаще рекомендуется, ссылка. Но я пока не дошел до того, чтобы все было настолько хорошо, чтобы можно было легко использовать ссылки. Используются стандартные методы HTTP (GET, POST, PUT, DELETE) — т. к. они уже заложены в составе протокола, мы их можем использовать для того, чтобы построить каркас взаимодействия с нашим сервером. Сервер не хранит состояние — это значит, сервер не отделяет один вызов от другого, не сохраняет все сессии в памяти. Если у вас есть какое-либо масштабируемое облако, какая-то ферма из серверов, которая реализует ваш сервис, нет необходимости обеспечивать согласованность состояния этих сервисов между всеми узлами, которые у вас есть. Это сильно упрощает масштабирование — при добавлении еще одного узла все прекрасно работает.
Чем REST хорош?
Он очень прост! Мы переиспользуем существующие стандарты, которые в ходу уже очень давно и применяются на многих устройствах. REST основывается на HTTP => доступны все плюшки: Кэширование. Масштабирование. Минимум накладных расходов. Стандартные коды ошибок.
Очень хорошая распространенность (даже IoT-устройства уже умеют работать на HTTP).
Лучшие решения (независимые от технологий)
Какие в современном мире есть лучшие решения, не связанные с конкретной реализацией? Эти решения советую использовать обязательно:
SSL повсюду — самое важное в вашем сервисе, т. к. без SSL авторизация и аутентификация бессмысленны. Документация и версионность сервиса — с первого дня работы. Методы POST и PUT должны возвращать обратно объект, который они изменили или создали, — это позволит сократить время обращения к сервису вдвое. Поддержка фильтрации, сортировки и постраничного вывода — очень желательно, чтобы это было стандартно и работало «из коробки». Поддержка MediaType. MediaType — способ сказать серверу, в каком формате вы хотите получить содержимое. Если вы возьмете какую-либо стандартную реализацию web API и зайдете туда из браузера, API отдаст вам XML, а если зайдете через какой-нибудь Postman, он вернет JSON. Prettyprint & gzip. Не минимизируйте запросы и не делайте компакт для JSON (того ответа, который придет от сервера). Накладные расходы на prettyprint —единицы процентов, что видно, если посмотреть, сколько занимают табы по отношению к общему размеру сообщения. Если вы уберете табы и будете присылать все в одну строку, запаритесь с отладкой. Что касается gzip, он дает выигрыш в разы. Т. ч. очень советую использовать и prettyprint, и gzip. Используйте только стандартный механизм кэширования (ETag) и Last-Modified (дата последнего изменения) — этих двух параметров серверу достаточно, чтобы клиент понял, что содержимое не требует обновления. Придумывать что-то свое тут не имеет смысла. Всегда используйте стандартные коды ошибок HTTP. Иначе вам однажды придется кому-нибудь объяснять, почему вы решили, что ошибку 419 в вашем проекте клиенту нужно трактовать именно так, как вы почему-то придумали. Это неудобно и некрасиво — за это клиент вам спасибо не скажет!
REST API REST API обеспечивают гибкую, упрощенную интеграцию приложений, а также являются самым популярным методом связывания компонентов в микросервисных архитектурах. Что такое REST API? API или программный интерфейс приложения представляет собой набор правил, определяющих способ взаимодействия между приложениями или устройствами. REST API — это API, соответствующий принципам архитектурного стиля REST (от англ. Representational State Transfer — «передача состояния представления»). По этой причине REST API иногда называют RESTful API.
REST (сам термин был введен Роем Филдингом в его докторской диссертации в 2000 году) обеспечивает относительно высокий уровень гибкости и свободы для разработчиков. Но гибкость — лишь одна из причин, объясняющих популярность REST API как способа взаимодействия между компонентами и приложениями в микросервисной архитектуре.
Принципы проектирования REST На самом базовом уровне API можно представить как механизм, с помощью которого одно приложение или сервис может получить доступ к ресурсу другого приложения или сервиса. Приложение или сервис, запрашивающий доступ, называется клиентом, а приложение или сервис, обладающий необходимым ресурсом, называется сервером.
Некоторые API, например SOAP или XML-RPC, устанавливают строгие ограничения для разработчиков. Однако для разработки REST API можно использовать практически любой язык программирования и разнообразные форматы данных. Единственное требование заключается в соблюдении шести принципов проектирования REST, известных также как архитектурные ограничения:
Единый интерфейс. Все запросы API к одному и тому же ресурсу должны выглядеть одинаково, независимо от отправителя. В REST API один и тот же элемент данных, например имя или адрес электронной почты пользователя, должен принадлежать одному универсальному коду ресурса (URI). Размер ресурсов не должен быть слишком большим, однако ресурсы должны содержать всю информацию, которая может потребоваться клиенту. Разделение клиента и сервера. В соответствии с требованиями REST API клиент и сервер должны работать полностью независимо друг от друга. Клиентскому приложению достаточно знать URI запрашиваемого ресурса; иначе взаимодействие с серверным приложением будет невозможно. Аналогичным образом, серверное приложение не должно вносить никаких изменений в клиентское приложение, а только передавать запрошенные данные через HTTP. Отсутствие сохранения состояния. REST API функционируют без сохранения состояния, т. е. каждый запрос должен содержать всю информацию, необходимую для его обработки. Другими словами, для REST API не требуется установление постоянных сеансов с сервером. Серверным приложениям запрещено хранить какие-либо данные, связанные с запросом клиента. Поддержка кэширования. По возможности ресурсы должны поддерживать кэширование на стороне клиента или сервера. Ответы сервера также должны хранить информацию о том, разрешено ли кэширование для предоставленного ресурса. Это позволяет увеличить производительность на стороне клиента, одновременно повысив масштабируемость на стороне сервера. Многоуровневая архитектура системы. В REST API вызовы и ответы передаются через разные уровни. Предполагается, что клиентское и серверное приложения не взаимодействуют между собой напрямую. Цепочка передачи данных может включать несколько промежуточных узлов. REST API должны проектироваться таким образом, чтобы ни клиент, ни сервер не могли знать, взаимодействуют они с конечным приложением или промежуточным узлом. Код по требованию (необязательное требование). REST API обычно отправляют статические ресурсы, однако в некоторых случаях ответ может содержать исполняемый код (например, Java-апплеты). В таких случаях код должен выполняться только по требованию. Принцип работы REST API REST API используют запросы HTTP для выполнения стандартных функций базы данных, таких как создание, чтение, обновление и удаление записей (так называемые функции CRUD). Например, REST API может использовать запрос GET для получения записи, запрос POST для создания записи, запрос PUT для обновления записи и запрос DELETE для удаления записи. В вызовах API поддерживаются все методы HTTP. Хорошо продуманный REST API можно сравнить с веб-сайтом, который работает в веб-браузере со встроенной поддержкой HTTP.
Состояние ресурса в любой момент времени («отметка времени») называется представлением ресурса. Эта информация может быть предоставлена клиенту практически в любом формате, включая JavaScript Object Notation (JSON), HTML, XLT, Python, PHP или текстовом формате. Популярность JSON обусловлена тем, что данный формат не зависит от языка программирования и понятен как человеку, так и компьютеру.
Важную роль в вызовах REST API также играют заголовки и параметры запросов, поскольку они содержат такую важную информацию, как метаданные, разрешения, универсальные коды ресурсов (URI), сведения о кэшировании, файлы cookie и многое другое. Заголовки запросов и ответов применяются в хорошо продуманных REST API вместе с обычными кодами состояния HTTP.
Рекомендации по использованию REST API С одной стороны, гибкость является огромным преимуществом при проектировании REST API; с другой стороны, гибкость может стать причиной дефективного или неэффективного API. По этой причине профессиональные разработчики делятся передовыми практиками в спецификациях REST API.
Спецификация OpenAPI (OAS) определяет интерфейс для описания API, чтобы обеспечить разработчикам и приложениям полное понимание всех параметров и возможностей API, включая доступные конечные точки, разрешенные операции для каждой конечной точки, параметры операций, методы аутентификации и прочую информацию. Последняя версия, OAS3 (внешняя ссылка), содержит полезные инструменты, например OpenAPI Generator, для создания клиентов API и серверных заглушек на разных языках программирования.
Для обеспечения безопасности REST API также следует опираться на передовой отраслевой опыт, в частности использование алгоритмов хэширования для защиты паролей и HTTPS для безопасной передачи данных. Для ограничения прав доступа сторонних приложений можно использовать инфраструктуру авторизации, например OAuth 2.0 (внешняя ссылка). Кроме того, API может отклонять любые запросы, поступающие по истечении определенного периода времени, используя отметку времени в заголовке HTTP. Существуют и другие способы контроля доступа к API: проверка параметров и веб-маркеры JSON.
Часть 1. Что такое REST REST, как и многое в мире IT, — это акроним, сокращение от английского Representational State Transfer — передача состояния представления.
Это архитектурный стиль взаимодействия компонентов распределенной системы в компьютерной сети. Проще говоря, REST определяет стиль взаимодействия (обмена данными) между разными компонентами системы, каждая из которых может физически располагаться в разных местах.
Данный архитектурный стиль представляет собой согласованный набор ограничений, учитываемых при проектировании распределенной системы. Эти ограничения иногда называют принципами REST. Их немного, всего 6 штук. О них мы поговорим чуть позже. Приложения, построенные с учетом REST, т.е. не нарушающие накладываемые REST ограничения, называют RESTful. История возникновения REST Термин REST ввел Рой Филдинг, один из создателей протокола HTTP, в своей докторской диссертации "Архитектурные стили и дизайн сетевых программных архитектур" ("Architectural Styles and the Design of Network-based Software Architectures") в 2000 году. Можно сказать, что термин REST еще молодой, хотя его концепция лежит в самой основе всемирной паутины.
Мы не будем погружаться глубоко в историю возникновения данного термина. Если хочешь окунуться в первоисточники, загляни в диссертацию Филдинга. REST ограничения и принципы Как было сказано выше, REST определяет, как компоненты распределенной системы должны взаимодействовать друг с другом. В общем случае это происходит посредством запросов-ответов. Компоненту, которая отправляет запрос называют клиентом; компоненту, которая обрабатывает запрос и отправляет клиенту ответ, называют сервером. Запросы и ответы, чаще всего, отправляются по протоколу HTTP (англ. HyperText Transfer Protocol — "протокол передачи гипертекста").
Как правило сервер — это некое веб-приложение. Клиентом же может быть не то чтобы что угодно, но довольно многое. Например, мобильное приложение, которое запрашивает у сервера данные. Либо браузер, который отправляет запросы с веб-страницы на сервер для загрузки данных.
Приложение А может запрашивать данные у приложения Б. Тогда А является клиентом по отношению к Б, а Б — сервером по отношению к А. Одновременно с этим, А может обрабатывать запросы от В, Г, Д и т.д. В таком случае, приложение А является одновременно и сервером, и клиентом. Все зависит от контекста.
Однозначно одно: компонента которая шлет запрос — это клиент. Компонента, которая принимает, обрабатывает и отвечает на запрос — сервер.
Однако не каждая система, чьи компоненты обмениваются данными посредством запросов-ответов, является REST (или же RESTful) системой. Чтобы система считалась RESTful, она должна “вписываться” в шесть REST ограничений:
- Приведение архитектуры к модели клиент-сервер В основе данного ограничения лежит разграничение потребностей. Необходимо отделять потребности клиентского интерфейса от потребностей сервера, хранящего данные. Данное ограничение повышает переносимость клиентского кода на другие платформы, а упрощение серверной части улучшает масштабируемость системы. Само разграничение на “клиент” и “сервер” позволяет им развиваться независимо друг от друга.
- Отсутствие состояния Архитектура REST требует соблюдения следующего условия. В период между запросами серверу не нужно хранить информацию о состоянии клиента и наоборот. Все запросы от клиента должны быть составлены так, чтобы сервер получил всю необходимую информацию для выполнения запроса. Таким образом и сервер, и клиент могут "понимать" любое принятое сообщение, не опираясь при этом на предыдущие сообщения.
- Кэширование Клиенты могут выполнять кэширование ответов сервера. У тех, в свою очередь, должно быть явное или неявное обозначение как кэшируемых или некэшируемых, чтобы клиенты в ответ на последующие запросы не получали устаревшие или неверные данные.
Правильное использование кэширования помогает полностью или частично устранить некоторые клиент-серверные взаимодействия, ещё больше повышая производительность и расширяемость системы.
- Единообразие интерфейса К фундаментальным требованиям REST архитектуры относится и унифицированный, единообразный интерфейс. Клиент должен всегда понимать, в каком формате и на какие адреса ему нужно слать запрос, а сервер, в свою очередь, также должен понимать, в каком формате ему следует отвечать на запросы клиента. Этот единый формат клиент-серверного взаимодействия, который описывает, что, куда, в каком виде и как отсылать и является унифицированным интерфейсом
- Слои Под слоями подразумевается иерархическая структура сетей. Иногда клиент может общаться напрямую с сервером, а иногда — просто с промежуточным узлом. Применение промежуточных серверов способно повысить масштабируемость за счёт балансировки нагрузки и распределённого кэширования.
Приведем пример.
Представим себе некоторое мобильное приложение, которое пользуется популярностью во всем мире. Его неотъемлемая часть — загрузка картинок. Так как пользователей — миллионы человек, один сервер не смог бы выдержать такой большой нагрузки.
Разграничение системы на слои решит эту проблему. Клиент запросит картинку у промежуточного узла, промежуточный узел запросит картинку у сервера, который наименее загружен в данный момент, и вернет картинку клиенту. Если здесь на каждом уровне иерархии правильно применить кэширование, то можно добиться хорошей масштабируемости системы. 6. Код по требованию (необязательное ограничение) Данное ограничение подразумевает, что клиент может расширять свою функциональность, за счет загрузки кода с сервера в виде апплетов или сценариев. Обзор REST. Часть 1: что такое REST - 2 Преимущества, которые дает REST У приложений, которые соблюдают все вышеперечисленные ограничения, есть такие преимущества: надёжность (не нужно сохранять информацию о состоянии клиента, которая может быть утеряна); производительность (за счёт использования кэша); масштабируемость; прозрачность системы взаимодействия; простота интерфейсов; портативность компонентов; лёгкость внесения изменений; способность эволюционировать, приспосабливаясь к новым требованиям.
В настоящее время существует значительное количество различных форматов, рекомендуемых в литературе для использования в распределенных информационных системах. Чаще всего в сообществе разработчиков, предпочтение отдают одному из трёх наиболее используемых форматов обмена данными: XML, JSON, YAML.
XML (Extensible Markup Language) – простой, очень гибкий текстовый формат, являющийся подмножеством SGML (ISO 8879) [3], который позволяет определять собственные теги и атрибуты. Язык называется расширяемым, поскольку он не фиксирует разметку, используемую в документах: разработчик волен создать ее в соответствии с особенностями конкретной предметной области, будучи ограниченным лишь синтаксическими правилами языка [4]. Возможность создания собственных тегов делает XML универсальным.
JSON (Java Script Object Notation) – представляет собой облегченный формат обмена данными между компьютерами [5]. В соответствии с определением стандарта сценарного языка программирования ECMA (Европейской ассоциации производителей компьютеров), он является производным от литералов Java Script. JSON более компактен, чем XML, его конструкции легче анализируются средствами Java Script, для которого JSON является внутренним используемым типом данных. Основная сфера применения JSON – программирование web-приложений, где он служит альтернативой XML.
YAML – человекочитаемый формат сериализации данных, концептуально близкий к языкам разметки, но ориентированный на удобство ввода-вывода типичных структур данных многих языков программирования. В настоящее время акроним YAML интерпретируется как «YAML Ain’t Markup Language» («YAML – не язык разметки»). В названии отражена история развития: на ранних этапах акроним представлял собой аббревиатуру выражения «Yet Another Markup Language» («Ещё один язык разметки») и даже рассматривался как конкурент XML, но позже был переименован, чтобв акцентировать внимание на данных, а не на разметке документов.
В настоящее время не существует сформулированных критериев, благодаря которым можно было бы сравнить форматы обмена данными в приложениях с клиент-серверной архитектурой. Однако на различных ресурсах, посвященных IT-тематике, профессиональными разработчиками и архитекторами информационных систем не раз делались попытки такие критерии рекомендовать. Стоит отметить, что, несмотря на значительное число характерных черт, рекомендованных в качестве критериев сравнения, не все они представляют теоретическую или практическую пользу. Ниже представлены те критерии сравнительного анализа, которые в настоящее время представляются наиболее важными при принятии решения в процессе разработки клиент-серверного приложения.
-
Человекочитаемость – предполагает простую и удобную разметку передаваемых данных. При этом язык должен иметь незначительное количество символов-разделителей (скобки, кавычки и т.д.).
-
Простота сериализации – преобразования объекта (данных) в поток байтов для дальнейшего хранения или передачи по каналу связи, в память или файл.
-
Простота десериализации – преобразования потока байтов в объект данных.
-
Возможность проверки формата входных данных – наличие в формате обмена данными внутреннего языка описания структуры документа (JSON-Schema, XML-Schema), необходимого для осуществления предварительной проверки на соответствие приходящих данных, например, со стороны клиента.
-
Эффективность сжатия данных – включает скорость выполнения алгоритма компрессии и коэффициент сжатия.
-
Распространенность – наличие большого количества разработчиков, использующих тот или иной формат обмена данными.
-
Динамика развития, которая характеризуется скоростью популяризации и развития.
Нашел ошибку или есть что добавить? Обязательно напиши мне об этом, рад любой обратной связи. А лучше сразу закидывай пулл-реквест!