API Endpoint — это URL-адрес, который действует как точка контакта между клиентом API и сервером API. Клиенты API отправляют запросы к конечным точкам API для доступа к функциям и данным API.
Типичный REST API имеет множество конечных точек, соответствующих его доступным ресурсам. Например, API, который поддерживает приложение социальных сетей, скорее всего, будет включать конечные точки для пользователей, публикаций и комментариев. Запросы к конечным точкам API должны включать метод, который указывает операцию, которую необходимо выполнить, а также необходимые заголовки, параметры, учетные данные аутентификации и данные тела. Давайте вместе с FoxmindED рассмотрим, api endpoint что это, как работают конечные точки API, прежде чем рассмотреть некоторые рекомендации по их проектированию и разработке. Мы также рассмотрим различия между конечной точкой REST и конечной точкой GraphQL и обсудим, как платформа API Postman может помочь командам с легкостью создавать и использовать конечные точки API.
Как работают конечные точки API?
Итак, что такое endpoint api? Конечные точки API работают путем подключения клиентов и серверов API и обработки передачи данных между ними. Хорошо спроектированный API должен иметь четкие и интуитивно понятные конечные точки, которые обеспечивают предсказуемый способ взаимодействия клиентов с ресурсами сервера. Например, REST API, который поддерживает простое приложение для ведения блога, может иметь следующие конечные точки, доступ к которым можно получить с помощью указанных методов HTTP:
- /authors – для получения списка пользователей (GET) или создания нового пользователя (POST).
- /authors/:id – для получения определенного пользователя (GET), обновления существующего пользователя (PUT или PATCH) или удаления определенного пользователя (DELETE).
- /articles – получить список статей (GET) или создать новую статью (POST).
- /articles/:id – чтобы получить конкретную статью (GET), обновить существующую статью (PUT или PATCH) или удалить определенную статью (DELETE).
В этом примере мы видим, что API предоставляет два набора конечных точек: один для ресурса «Автор» и один для ресурса «Статья». Доступ к каждому ресурсу можно получить через две разные конечные точки, в зависимости от типа операции, которую клиент хочет выполнить. Например, если клиент заинтересован в просмотре всех авторов в базе данных, он отправит запрос GET в конечную точку /authors. Напротив, конечная точка /authors/:id позволяет клиенту просматривать, обновлять или удалять данные конкретного автора, включая идентификатор автора в качестве параметра запроса.
Клиент API отвечает за сборку и отправку запроса на сервер API. Помимо необходимых конечной точки и метода, запрос может также включать параметры, заголовки HTTP и тело запроса. Давайте рассмотрим эти компоненты запроса немного подробнее.
Параметры
Это переменные, которые передаются в конечную точку API и предоставляют конкретные инструкции для обработки API. Например, конечная точка /articles нашего простого приложения для ведения блога может принимать параметр категории, который будет использоваться для получения статей указанной категории.
Заголовки запроса
Это пары «ключ-значение», которые предоставляют дополнительную информацию о запросе. Например, заголовок Accept определяет типы мультимедиа, которые может принимать клиент, а заголовок Authorization используется для отправки токенов и ключей API для аутентификации клиента.
«Тело» запроса
Оно включает фактические данные, необходимые для создания, обновления или удаления ресурса. Например, если автор хочет создать новую статью в нашем примере приложения для ведения блога, он отправит запрос POST на конечную точку /articles с содержимым статьи в теле запроса.
Как только клиент отправляет запрос в соответствующую конечную точку, сервер API аутентифицирует его, проверяет входные данные, извлекает или манипулирует соответствующими данными и возвращает ответ клиенту. Ответ обычно включает в себя код состояния, который указывает результат запроса, а также тело, содержащее фактические данные, запрошенные клиентом (если запрос был успешно выполнен).
Каковы рекомендации по проектированию и разработке конечных точек API?
Конечные точки API необходимы для работоспособности и производительности любого приложения. Следующие рекомендации помогут вам проектировать, разрабатывать и обслуживать надежные, масштабируемые, удобные и безопасные конечные точки.
- Создайте предсказуемую и интуитивно понятную структуру конечных точек API
При определении конечных точек вашего API важно использовать четкое и интуитивно понятное соглашение и структуру именования. По возможности одни и те же соглашения должны применяться ко всем API в вашем цифровом портфолио. Такая согласованность поможет создать предсказуемый пользовательский опыт для потребителей вашего API, упрощая им интеграцию с вашим API.
- Внедрите механизмы безопасной аутентификации
Конечные точки API — это ворота к данным приложения, что делает их привлекательными объектами атак. Аутентификация API включает проверку личности клиента, отправляющего запрос API, и играет решающую роль в усилении безопасности API. Поэтому важно использовать хорошо зарекомендовавшие себя механизмы аутентификации, такие как OAuth, OpenID Connect или JWT, особенно если ваши конечные точки предоставляют доступ к конфиденциальным данным.
- Проверьте и очистите входные данные
Проверка ввода — это процесс подтверждения того, что любые данные, отправляемые в API, соответствуют ожидаемому формату и ограничениям, а очистка помогает гарантировать, что входные данные не содержат вредоносных символов. Эти процессы следует выполнять на уровне метода, чтобы предотвратить попадание любого вредоносного кода в рабочий процесс, где он может изменить разрешения или записи базы данных.
- Четко документируйте каждую конечную точку API
Документация API играет важную роль в общем успехе API. Документация по частному API облегчает сотрудничество между командами и уменьшает дублирование кода, а общедоступная документация по API помогает потенциальным потребителям понять API и поэкспериментировать с ним. Поэтому производителям API крайне важно тщательно документировать каждую конечную точку API, включая ее методы, параметры и принятые типы данных. Они также должны описать — простым языком — то, для чего предназначена каждая конечная точка.
- Постоянно тестируйте и отслеживайте конечные точки API
Тестирование API помогает гарантировать, что конечные точки API работают должным образом, даже по мере развития API. Модульные тесты подтверждают, что одна конечная точка возвращает правильный ответ на заданный запрос, а сквозные тесты проверяют сложные рабочие процессы, которые могут включать несколько конечных точек. Автоматизация тестирования API может помочь командам автоматически выявлять проблемы на протяжении всего процесса разработки, а мониторинг API использует ту же логику для отслеживания конечных точек API, когда они уже запущены в эксплуатацию.
В чем разница между конечной точкой REST и конечной точкой GraphQL?
В этой статье в качестве примеров использовались конечные точки REST API, поскольку REST сегодня является наиболее часто используемой архитектурой API. Но, существует множество других архитектур и протоколов API, включая GraphQL, язык запросов с открытым исходным кодом для API.
Между конечными точками REST и GraphQL существуют существенные различия. API REST включают в себя множество конечных точек, которые возвращают фиксированные структуры данных, что может потребовать от клиента объединить несколько запросов вместе, чтобы получить именно те данные, которые ему нужны. Например, пользователю приложения для ведения блога может быть интересно просмотреть все сообщения автора по имени Кейт Висли. Таким образом, этот пользователь может отправить запрос GET на конечную точку /authors и включить «Кейт Висли» в качестве значения параметра запроса имени. Ответ будет включать идентификатор Кейт Висли, который пользователь затем включит в последующий цепной запрос к конечной точке /authors/:id/articles.
Напротив, GraphQL позволяет клиентам взаимодействовать с одной конечной точкой и указывать точные данные, которые им нужны, без необходимости связывать несколько запросов вместе. Такой подход уменьшает количество обращений между клиентом и сервером, что может повысить надежность и производительность за счет уменьшения объема передаваемых данных.
Заключение
Мы живем в мире, который теперь ожидает открытого и доступного контента для всех. Естественным развитием этого процесса является то, что издатели сами выпускают свои собственные API, чтобы клиенты могли разрабатывать с их помощью приложения.
Совместное использование API применимо ко всем предприятиям, а не только к тем, которые основаны на веб-технологиях, а скорее у любого, у кого в организации есть веб-инструмент или компонент. Конечно, эта концепция вызовет препятствия для некоторых организаций, главным из которых является предоставление всем одинакового представления о том, как работают API.
Это легко, увязнуть в техническом жаргоне эндпоинт. Но, применительно к реальным случаям становится легче понять, как API работают так, как они работают. Надеемсяь, теперь вы лучше понимаете один из их ключевых компонентов — конечные точки!
Остались вопросы о том, что такое endpoint api? Спрашивайте в комментариях ниже!