Обмен данными между несколькими платформами как никогда важен в эпоху интеграций. Представьте себе интернет-магазин без интеграций. Вашему сайту пришлось бы разрабатывать системы для управления учетными записями пользователей, подписками на электронную почту, обработкой платежей, отправкой и другими задачами в дополнение к управлению списками товаров. Было бы эффективнее передать эти обязанности другим провайдерам, так как это не является масштабируемым вариантом.
Интерфейсы прикладного программирования, или веб-интерфейсы API, - это то, что используют программы для взаимодействия друг с другом. API предлагают последовательный протокол для обмена данными между двумя программами. С помощью веб-интерфейсов API ваш интернет-магазин может взаимодействовать с программами доставки, клиентскими приложениями, платежными приложениями и любыми другими необходимыми соединениями.
Существуют различные способы создания API; однако если вы хотите добавить программные соединения к своим сервисам, есть одна уникальная техника, с которой вы должны быть знакомы: веб-сервисы REST API. В этой статье мы обсудим примеры REST API, что такое REST API, как работает REST API, для чего используется REST API, историю, его элементы и многое другое.
Что именно представляет собой REST API?
Веб-сервисы Representational State Transfer или REST API являются наиболее стандартной практикой для связывания компонентов в микросервисных системах, поскольку они предлагают универсальный, портативный способ объединения приложений. REST - это популярный дизайн API, который мы используем для взаимодействия с внутренними и внешними заинтересованными сторонами в стандартизированной и предсказуемой манере.
Пользователи веб-приложений часто используют веб-сервисы REST API для взаимодействия друг с другом. Например, получение и просмотр данных учетной записи в программе социальной сети. Браузеры REST APIs можно рассматривать как синтаксис Интернета. Онлайновые клиенты используют веб-интерфейсы API для предоставления и управления доступом к цифровым операциям по мере роста использования облачных технологий.
Разработка веб-интерфейсов API, позволяющих клиентам подключаться, управлять и взаимодействовать с цифровыми веб-сервисами динамически в рассредоточенном контексте, является разумным решением. Такие веб-сайты, как Google, eBay, Facebook, Amazon и Twitter, используют RESTful веб-сервисы. Клиентские приложения теперь могут использовать REST для доступа к этим веб-службам.
Технология REST предпочтительнее других родственных технологий. Это связано с тем, что веб-службы REST потребляют меньше пропускной способности, что делает их идеальными для работы в Интернете. Веб-службы RESTful также могут быть разработаны с использованием таких языков программирования, как JavaScript или Python.
Как работают REST API?
Чтобы понять, как работают REST API, мы должны определить некоторые ключевые термины:
Клиент
Пользователь API называется клиентом. Клиент посылает запросы к веб-интерфейсам API для получения данных или внесения изменений в программу. Ваш интернет-браузер является клиентом; он взаимодействует с различными веб-интерфейсами API для получения содержимого страницы. Ваш компьютер получает необходимую информацию, которая затем выводится на экран.
Ниже перечислены наиболее популярные методы HTTP:
- Запрос GET используется для возврата запрошенных данных или запрашиваемых ресурсов.
- Используйте запрос POST для создания нового ресурса.
- Используйте команду PUT, чтобы внести изменения или продолжить обновление существующего ресурса
- Используйте команду DELETE, чтобы избавиться от ресурса.
Например, HTTP-запрос к API Youtube может представлять собой GET-запрос ресурса для получения определенного видео или поста или POST-запрос для публикации новой фотографии. Для публикации новых постов можно использовать метод запроса POST. Соответственно, платформа веб-услуг для клиентов, интегрированная с реализацией автосекретаря, может использовать инструкцию PUT для обновления или удаления пользовательского приветствия.
Запрос Get
- Кэширование GET-запросов возможно. История браузера включает GET-запросы.
- Возможно добавление GET-запросов в закладки.
- Никогда не используйте GET-запросы при работе с критическими материалами.
- Существуют ограничения на длину GET-запросов.
- Через GET-запросы выполняются только запросы данных.
Метод POST
Запрос POST - это почтовый метод отправки информации на сервер для добавления или обновления ресурсов. Тело HTTP-запроса содержит данные, которые публикуются на стороне сервера:
- POST-запросы пост-метода никогда не попадают в кэш.
- POST-запросы не сохраняются в истории браузера.
- POST-запросы не сохраняются в закладках.
Тело ответа
Тело ответа - один из важных элементов RESTful API. В тело ответа включаются запрошенные данные. Тело ответа может включать данные, относящиеся к выходным и выходным логическим портам.
Ресурс
Любые данные, которые веб-интерфейсы API могут предоставить пользователю, являются ресурсом. Например, человек, страница, картинка или замечание могут считаться ресурсами в API Facebook. Идентификатор ресурса - это специальный термин, присвоенный каждому ресурсу.
Веб-сервер
Программа, принимающая тело запроса потребителя, использует веб-сервер, на котором размещаются ресурсы, запрашиваемые потребителем. Сервер может общаться с клиентами через API, не предлагая потребителям немедленного доступа к информации, хранящейся в его базах данных. Когда пользователь обращается к RESTful веб-сервисам для отправки тела запроса, сервер отправляет браузеру нормализованное изображение состояния ресурса.
Это означает, что сервер каким-то образом не передает клиенту точный ресурс, а отражает его состояние, то есть положение ресурса на определенную временную метку. Для облегчения понимания ответы возвращаются в облегченном формате.
Широко используется JSON (JavaScript Object Notation), поскольку он понятен как людям, так и машинам, а также способствует повышению доступности веб-сайтов. JSON в основном используется для отправки тела запроса в веб-приложениях и клиентских приложениях. Он совместим с различными формами кодирования. Форматы данных API, отличные от JSON, включают XML, YAML, CSV, HTML и обычный текст. Пользователи API могут выбрать любой формат данных по своему усмотрению, используя пользовательские типы носителей.
История REST API
До появления REST API многим программистам приходилось работать с SOAP. Создание, использование и отладка SOAP, как известно, были сложными задачами. К счастью, REST был разработан командой программистов под руководством Роя Филдинга, навсегда изменив среду API.
Ниже приводится хронология развития API REST с течением времени:
До REST
Программисты вручную писали XML-файл, содержащий внутри контента вызов удаленной процедуры (RPC) для подключения веб-интерфейсов API с помощью SOAP. После этого разработчики отправляли свой SOAP-пакет в указанную конечную точку.
В 2000 г.
Команда программистов под руководством Роя Филдинга решила разработать структуру, позволяющую любому серверу взаимодействовать с любым другим сервером. Он установил ограничения для REST API. Поскольку эти рекомендации универсальны, разрабатывать программное обеспечение стало проще.
В 2002 году
В 2002 году eBay разработал свой RESTful API, открыв свою торговую площадку для любого сайта, который мог бы извлечь из этого выгоду. В связи с этим другой титан электронной коммерции, Amazon, заинтересовался этим и в 2002 году выпустил свой RESTful API.
В 2004-2006 гг.
В 2004 году были выпущены RESTful веб-сервисы Flickr, которые позволили авторам быстро добавлять фотографии на свои веб-сайты и в социальные сети. Когда Twitter и Facebook заметили, что значительное число программистов сканируют веб-сайты и создают API "Франкенштейна", они оба обнародовали свои API примерно два года спустя.
С 2006 года по настоящее время
RESTful веб-сервисы теперь широко признаны программистами, которые используют эти RESTful веб-сервисы для повышения производительности своих приложений и сайтов. AppMaster облегчает сотрудничество и упрощает построение API, позволяя делать это быстрее.
Для чего используются REST API?
Одно из главных преимуществ RESTful веб-сервисов заключается в том, что они обладают большой гибкостью, позволяя вам использовать RESTful API более эффективно. Ниже приведены примеры того, для чего используются REST API.
Облачные приложения
Благодаря безстатичности своих вызовов, REST API выгодно использовать в облачных приложениях. Модули без статических данных могут легко переустанавливаться и наращиваться для удовлетворения потребностей в мощности, если что-то пойдет не так. Программное обеспечение, сочетающее в себе локальные и интернет компоненты, является облачным приложением. В этой парадигме для выполнения инструкций используются удаленные серверы, доступ к которым осуществляется через веб-браузер и текущие веб-сервисы Интернета.
Традиционным местом размещения облачных приложений является удаленная компьютерная система, управляемая сторонним оператором сети облачных вычислений. Почта, обмен и хранение документов, ввод заказов, контроль инвентаризации, Microsoft Word, управление взаимоотношениями с клиентами(CRM), сбор информации, финансы и бухгалтерия - вот примеры работ, выполняемых с помощью облачных приложений.
Интерфейсы программирования приложений REST(API) могут использоваться для подключения внешних источников информации и ресурсов хранения. Программисты могут сделать облачные приложения более компактными, используя REST API для передачи данных другим программам для обработки или анализа вычислений и возврата полученных результатов в программу. Проверенные API обеспечивают активное единообразие, что позволяет ускорить производство и получить реальные результаты.
Ярким примером облачного приложения являются Google Docs или Office 365. Все, что требуется для работы с Google Docs или Office 365, - это компьютер, способный работать с поисковыми системами и веб-службами Интернета. Компьютерные сети обеспечивают пользовательский интерфейс и операции, включая хранение информации. Множество различных облачных приложений могут быть размещены в вашей компании с помощью хостеров облачных приложений.
Облачные сервисы
Поскольку для подключения к ресурсу через API необходимо управлять тем, как обрабатывается URL, REST API также полезны для облачных веб-сервисов. Архитектура RESTful веб-сервисов, вероятно, станет стандартной в будущем благодаря облачным приложениям. Программисты используют RESTful веб-сервисы для подключения к облачным сервисам с помощью интернета. Разработчик создает код, который использует API интернет-провайдера, предоставляет необходимые входные данные и переменные, а затем проверяет ответ, чтобы убедиться, что действие работает так, как ожидалось.
Конечные пользователи могут получить доступ к клиентским приложениям или веб-сервисам, предлагаемым облачными веб-сервисами, таким как вычислительная инфраструктура, системы хранения данных или системы отслеживания, используя облачный сервис типа RESTful веб-сервисов. API описывают возможности и операции приложения, а также специфику, необходимую для их выполнения. Для обеспечения конфиденциальности и безопасности клиента API часто зависят от совместимости REST или Simple Object Access Protocol (SOAP) и механизмов разрешения, таких как OAuth 2.0.
Различные веб-услуги называются "облачными услугами" и предоставляются предприятиям и потребителям в режиме онлайн по запросу. Эти веб-службы созданы для обеспечения быстрого и недорогого доступа к инструментам и приложениям без необходимости использования оборудования или инфраструктуры. Большинство сотрудников используют облачные веб-сервисы для всего, начиная от электронной почты и заканчивая совместной работой над документами.
Использование в Интернете
Эти веб-интерфейсы API можно получить из пользовательского веб-проекта, приложения для iPhone, устройства IoT или Windows Mobile, поскольку REST не зависит от функциональности на стороне клиента. Вы можете создавать архитектуру для своего бизнеса, не будучи ограничены конкретным фреймворком на стороне клиента.
Пример REST API
Давайте обсудим пример REST API. Щелкните по ссылке ниже, чтобы задать произвольный интеллектуальный запрос Open Trivia Database: Такие RESTful веб-службы были использованы для предоставления публичного веб-интерфейса API. Ваш компьютер отобразит одиночный вопрос викторины и ответы на него в формате JSON.
Используя любой HTTP-браузер, например url, вы можете задать следующий запрос и получить ответ в теле ответа: https://opentdb.com/api.php?amount=1&category=18.
Тело ответа в XML-файле веб-службы будет содержать всю информацию о сотруднике.
Все широко используемые диалекты программирования и инструменты разработчика имеют клиентские библиотеки HTTP, такие как retrieve в JavaScript, Node.js и Deno и file get contents() в PHP. Ответ в формате JSON можно читать и использовать, поскольку он поддается машинной обработке перед отображением в HTML или другом стиле.
Rest и REST API
Со временем появилось множество методов передачи данных. Возможно, вы сталкивались с такими вариантами, как CORBA, SOAP или XML-RPC. Большинство из них разработали строгие правила передачи сообщений. Рой Филдинг впервые описал REST в 2000 году, который гораздо более прост, чем другие.
Это скорее набор предложений и ограничений для веб-сервисов RESTful, чем норма. Они состоят из следующих архитектурных ограничений:
Разделение клиент-сервер
В архитектуре REST клиенты и веб-серверы могут взаимодействовать только в одном направлении: клиент запрашивает контроллер домена, а контроллер или сервер отвечает на запрос. Веб-серверы не могут отправлять запросы, а клиенты не могут реагировать; все соединения запускает потребитель.
Веб-службы RESTful позволяют изолировать потребителей и серверы, упрощая взаимодействие между ними. Клиентские компьютеры могут развиваться без опасения повлиять на другой хостинг, а материалы сервера могут быть изменены без невольного воздействия на потребителей.
Унифицированный интерфейс
Согласно этой стратегии, все запросы и реакции должны придерживаться стандартной процедуры proweb или стилизовать свои сообщения. Приложения и серверы разрабатываются на различных языках программирования, которые плохо взаимодействуют друг с другом с помощью посредника. Единый интерфейс - это диалект, который любой клиент может использовать для взаимодействия с любыми REST API.
Перевод запросов и реакций между приложениями с нормализованным взаимодействием был бы возможен только при наличии посредника. Незначительные различия приведут к мешанине и потере информации, и решениям придется обновлять свои процедуры запросов, когда веб-интерфейсы изменят свои. Согласованный интерфейс устраняет эту перспективу.
ПОЛУЧИТЬ ДОСТУП К https://www.googleapis.com/youtube/v3/channels?part=contentDetails
Как и все приложения REST-клиентов, данное предложение включает в себя два фрагмента данных. Техника HTTP - GET. Она описывает действие, которое клиент хочет произвести над ресурсами. Пользователь может использовать четыре основных метода HTTP:
HTTP, или Hyper-Text Transfer Protocol, является универсальным языком для большинства REST API. HTTP не был разработан с учетом REST. Кроме того, REST принял эту передачу данных в качестве критерия для REST-aware приложений. При использовании HTTP с REST API клиент отправляет запрос в формате, с которым вы, возможно, знакомы. Например, запрос к API YouTube выглядит следующим образом:
- Используйте команду GET для получения ресурса.
- Используйте команду POST, чтобы создать новый ресурс.
- Используйте команду PUT, чтобы внести изменения или продолжить обновление существующего ресурса
- Используйте запрос DELETE, чтобы избавиться от ресурса.
Методы HTTP определяют предполагаемое действие, которое должно быть предпринято в отношении определенного ресурса. Методы HTTP также известны как глаголы HTTB.
URL - это HTTP
Единый идентификатор ресурса, или URI, который идентифицирует предполагаемый ресурс, содержится в URL. URL также является конечной точкой в этом сценарии, поскольку именно здесь RESTful API вступает в контакт с пользователем сервиса.
Строка запроса: URL включает в себя строку запроса. Строка запроса используется для определения параметров, которым присваиваются значения.
После получения и проверки запроса веб-сервер возвращает данные о целевом ресурсе. Как правило, данные возвращаются в структуре, известной как JSON (JavaScript Object Notation). JSON представляет все компоненты ресурса в переносимом формате, который легко читается человеком.
Принципы унифицированного интерфейса
Единый интерфейс должен соответствовать следующим параметрам:
HATEOAS: Гипермедиа как двигатель состояния приложения
Гипермедиа является двигателем, лежащим в основе RESTful веб-сервисов. Это означает, что гипермедиа - это все, что клиент хочет постичь, чтобы распознать ответ провайдера.
- Только первый URI клиентского приложения должен быть предоставлен клиенту. Клиентское приложение должно непрерывно вести все остальные материалы и действия с помощью гиперссылок.
- Веб-службы RESTful не требуют языка входных запросов (IDL), что отличает их от других API.
Медиатип - это название формата данных представления. Медиатип определяет определение, которое описывает, как следует обращаться с изображением. Веб-интерфейс API, использующий REST, похож на гипертекст. Каждый элемент данных, к которому можно обратиться, имеет свое местоположение, прямое (например, через свойства ссылки и идентификации) или неявное (например, полученное из структуры описания медиатипа).
Само описательные сообщения
Каждая коммуникация между клиентской и серверной сторонами должна предоставлять достаточно данных для выполнения коммуникации. Соответственно, запрос от клиентской стороны к серверной должен указывать ресурс, к которому пытаются получить доступ, а также конкретные цели.
Кроме того, изображения ресурсов должны быть само описательными; пользователь не должен знать, является ли ресурс человеком или частью оборудования. Вместо этого, он должен реагировать, следуя типу медиа, связанному с помощью.
Поэтому, бесспорно, мы разработаем множество уникальных типов медиа, часто по одному типу медиа на ресурс. Каждый тип медиа определяет стандартную парадигму производства. Например, HTML определяет, как отображается гипертекст и как браузер обрабатывает каждый компонент.Идентификация ресурсов
Ресурсы, на которые ссылаются в обратной связи между клиентом и сервером, должны быть узнаваемы с помощью изображений. Придерживаться системы унифицированных идентификаторов ресурсов (URI) позволило это сделать. Другими словами, сообщение от сервера к клиенту может включать HTML-версию документа и некоторую информацию, а не реальный файл из хранилища сервера.
Потребитель может легко понять HTML-версию, поскольку она следует шаблону URI. Потребитель должен модифицировать ресурсы, предоставляя серверу изображение того, как ресурс должен в конечном итоге выглядеть. Это позволит потребителю создавать, извлекать, изменять и удалять ресурсы. Если у клиента есть необходимые полномочия для изменения данных, сервер должен выполнить запрос.
Stateless
В RESTful API все клиентские запросы должны быть переходными. В результате каждый запрос и тело ответа включают все данные, необходимые для заключения контракта, что делает каждое соединение автономным. Сервер не отслеживает предыдущие HTTP-запросы; он рассматривает каждый запрос клиента как совершенно новый.
Поскольку серверу не нужно выполнять никаких дополнительных задач для получения исторических данных, транспорт без статических данных значительно минимизирует объем памяти, необходимой серверу, и повышает вероятность того, что ответ будет приемлемым. Это гарантирует масштабируемость таких взаимодействий: программистам не нужно беспокоиться о том, что при расширении программного обеспечения и выполнении HTTP-запросов они будут использовать больше памяти или нагружать сервер.
Многоуровневый
До сих пор мы определяли запросы веб-API как прямой обмен между клиентом и сервером, хотя это несколько упрощает ситуацию. Между этими двумя организациями часто находится больше серверов. Эти платформы, или слои, существуют для управления и рассеивания трафика, добавления защиты и выполнения различных других важных задач.
Согласно этой концепции, сообщения, передаваемые между пользователем и целевым сервером, должны быть структурированы и обработаны одинаково, независимо от того, какие слои существуют между ними. Дополнительные слои не должны мешать взаимодействию с клиентами. Программисты, придерживающиеся этого правила, могут менять серверные системы, не затрагивая фундаментальный процесс "запрос-ответ".
Кэшируемый
Кэширование происходит, когда клиент просматривает веб-сайт, когда содержимое сохраняется на машине клиента. Кэшированный материал быстро загружается из внутренней памяти, а не загружается снова с сервера, когда пользователь посещает этот сайт позже. Большинство крупных сайтов используют кэширование для снижения нагрузки на страницы, экономя при этом место на сервере и пропускную способность.
Кэширование данных учитывается при разработке REST API. В ответе, который сервер выдает клиенту, должно быть указано, можно ли хранить данный ресурс и как долго.
Востребованный код
Последний постулат REST является излишним. По запросу ответ API может содержать программный код для использования клиентами. Благодаря этому клиент может выполнить клиентское приложение или программу в своем бэкенде.
API считается RESTful API, если он соответствует этому набору рекомендаций. Однако эти рекомендации предоставляют программистам большую свободу в изменении функций их RESTful API. REST API отличаются от простого протокола доступа к объектам (Simple Object Access Protocol), еще одной популярной методики веб-интерфейсов, тем, что они более гибкие (SOAP).
Консенсус по конечным точкам
Примите во внимание эти конечные точки:
- /user/123\s
- /user/id/123\s
- /user/123\s/user/id/123\s
- /user/?id=123
Все они являются законными методами получения данных клиентом 123. Когда появляются более сложные процедуры, количество возможностей возрастает. Например, в обратном порядке, начиная с записи 51, вывести 10 человек с фамилиями, начинающимися на "А", которые работают в компании.
В конечном счете, неважно, как вы структурируете URL; важно единообразие во всем RESTful API. В огромных программных системах с большим количеством программистов это не так просто. Модификации RESTful API неизбежны, но URL конечных точек никогда не должны быть отклонены, поскольку это приведет к тому, что приложения, которые на них полагаются, перестанут работать.
Версионирование REST API
Версионирование API является распространенной практикой для предотвращения несовместимости. Например, /2.0/user/123 заменяет /user/123. Старая и новая конечные точки могут продолжать функционировать. Следовательно, это заставляет поддерживать прошлые важные API. В конечном итоге предыдущие версии могут быть отправлены на пенсию, но эта процедура должна быть тщательно продумана.
Аутентификация REST API
Любое устройство может загрузить квип без авторизации, используя API запросов. API, которые читают приватную информацию или позволяют редактировать и удалять запросы, не поддерживают этого. Программы на стороне клиента в том же домене, что и веб-службы RESTful, отправляют и получают куки так же, как и HTTP-запросы. (Обратите внимание, что в ранних сайтах для Fetch() должна быть указана опция перезапуска привилегий). Запрос API может быть проверен, чтобы подтвердить, что пользователь вошел в систему и имеет необходимые разрешения.
Базовая аутентификация HTTP: Сторонние программы должны использовать различные решения по утверждению. Некоторые популярные методы проверки подлинности - это первичная проверка для:
- HTTP. Строка имя пользователя: пароль в кодировке base64 указывается в поле запроса как часть заголовка HTTP Approval.
- API-ключи: Предоставление ключа RESTful API, который может иметь специальные разрешения или быть ограничен одним сайтом, делает API доступным для сторонних приложений. Каждое сообщение содержит ключ либо в строке запроса, либо в заголовке HTTP. (Строка запроса - это компонент URL).
- OAuth: Перед выполнением запросов идентификатор клиента и, возможно, секрет клиента отправляются на сервер OAuth для получения учетной записи. До истечения срока действия учетные данные OAuth передаются вместе с каждым запросом API.
- Интернет-токены в JSON (JWT): Заголовок запроса и заголовок ответа надежно передают подписанные цифровой подписью учетные данные пользователя. JWT позволяют серверу шифровать привилегии доступа, устраняя необходимость запрашивать базу данных или использовать другой механизм аутентификации.
Сценарий использования влияет на способ аутентификации API:
- Иногда со сторонней программой работают как с любым другим вошедшим в систему клиентом с теми же привилегиями и правами. Например, API карты может предоставить запрашивающей программе указания между двумя точками. Он должен проверить, что программа является легитимным пользователем, но ему не нужно проверять учетные данные клиента.
- В других ситуациях сторонняя программа запрашивает личную информацию у конкретного пользователя, например, содержимое почты. API REST должны распознавать клиента и его полномочия, но они не должны беспокоиться о вызывающей программе.
Безопасность REST API
Веб-службы RESTful добавляют еще один способ взаимодействия с вашим программным обеспечением и влияния на него. Даже если ваш хост не является объектом повышенного внимания хакеров, недобросовестный пользователь может отправлять сотни запросов в секунду и разрушить его. В этой статье не рассматриваются вопросы безопасности, но стандартные лучшие процедуры подразумевают это:
Использовать HTTPS
Использовать надежный механизм аутентификации
CORS можно использовать для ограничения обращений клиентов к определенным областям.
Предоставлять необходимые возможности - то есть не
генерировать варианты DELETE, которые не являются необходимыми; проверять все URL конечных точек и информацию о теле.
Блокируйте ссылки из неопознанных секторов или IP-адресов, не подвергая ваучеры API в JavaScript на стороне клиента.
Ненормально большие пакеты блокируются.
Подумайте об ограничении скорости, когда запросы с одного IP-адреса или учетной записи API ограничены N запросами в минуту.
Ответ с правильным кодом состояния HTTP, запросы в журнале заголовков кэша и безуспешное расследование
Многочисленные запросы и ненужные данные
Развертывание веб-служб RESTful имеет ограничения. Возможно, что ответ содержит больше информации, чем вы запрашивали, или что для получения всей информации требуется несколько запросов. Подумайте о веб-службах RESTful, которые предоставляют пользователям доступ к информации о создателях и книгах; клиент может:
- Запросить информацию о первых 10 книгах, перечисленных в порядке покупки (первый продавец). Коллекция книг вместе с идентификатором каждого писателя включается в ответ.
Чтобы получить информацию по каждому писателю, создайте до 10 запросов /author/id.
N запросов API должны быть сгенерированы для каждого ответа на родительский запрос, что характеризуется как "проблема N+1".
Если это часто используемая ситуация, веб-службы RESTful могут быть модифицированы, чтобы включать всю информацию о писателе для каждой выпущенной книги, включая имя, пол, национальность, биографию и так далее. Можно предоставить даже больше информации об их предыдущих книгах, хотя это значительно увеличит нагрузку на ответ. API может быть изменен, чтобы сделать информацию о писателе необязательной. Author details=full для предотвращения ненужно больших ответов. Огромное количество вариантов, которые должны поддерживать разработчики API, может оказаться непосильным.
Подведение итогов
Теперь вы хорошо знаете REST API, как работают REST API, примеры REST API, для чего используются REST API, архитектурные ограничения и другие темы, рассмотренные в этом учебнике. Программистам может показаться сложным и пугающим изучение API, но платформа no-code AppMaster создала новую доступную библиотеку REST API, в которой вы можете углубить свои знания о ряде REST API для дальнейшего профессионального развития.
В AppMaster мы стараемся повысить доступность и удобство использования API. Мы хотим, чтобы вы узнали, поэкспериментировали и осознали преимущества использования API в своей карьере и личной жизни. Чтобы помочь вам быстрее разрабатывать лучшие веб-интерфейсы API, AppMaster улучшает совместную работу и автоматизирует каждый этап жизненного цикла API. Продолжайте создавать, совершенствовать и расширять свое понимание REST API.
