Increased api errors

Интерфейс прикладного программирования (API) — это программный интерфейс, который служит средой для соединения компьютеров и компьютерных программ. API становятся все более ценными, поскольку они приносят большую часть доходов многих компаний, включая такие компании, как Google, Amazon и Salesforce. Сегодня API-интерфейсы обзавелись полезными функциями, которые только увеличили их ценность. Например, современные API-интерфейсы придерживаются удобных для разработчиков стандартов (таких как HTTP) и имеют собственный жизненный цикл разработки программного обеспечения (SDLC).

Создание API может быть быстрым и простым, однако создание безопасной конфигурации требует больше усилий и точности. Разработчики API — это всего лишь люди, поэтому могут возникать ошибки, которые в конечном итоге могут повлиять на работу пользователей. Ниже приведены несколько самых распространенных ошибок API.

Использование http:// вместо https://

Хотя иногда API поддерживает и HTTP, и HTTPS, отсутствие одной буквы «s» может привести к ошибкам разработчика. Например, некоторые API-интерфейсы перенаправляют HTTP-трафик на HTTPS-аналог, но не все фреймворки будут настроены на отслеживание кода состояния 302. Некоторые API-интерфейсы также могут перестать поддерживать HTTP, и, хотя хорошие поставщики API будут сообщать пользователям заранее об этом, важно быть в курсе любых изменений.

Устаревшее кэширование

Кэширование необходимо для Интернета и взаимодействия с пользователем. Сохраняя данные в общедоступный файл, пользователи могут снова и снова обращаться к одним и тем же ресурсам, не перегружая сервер. Кэширование, как правило, отличная практика, но неправильная реализация может быть помехой и неприятностью.

Например, скажем, есть система API электронной коммерции, которая настроена на частое кэширование, чтобы обновлять запасы и снижать нагрузку на сервер во время циклов занятости. Если у API есть крупная распродажа, в конечную точку листинга будет добавлено большее количество товаров. Однако становится проблематичным то, как данные представляются, когда конечная точка листинга кэшируется. Клиенты в этом случае могут видеть новые данные, если данные представлены в реальном времени через динамический веб-сайт.

При этом плохо реализованное кэширование может привести к кликабельному элементу, изображению и даже описанию. И, как итог, страница 404 по щелчку мыши. Это происходит потому, что разрешение для этой конечной точки еще не кэшировано.

В этом случае важно, чтобы разработчик тестировал API так, как если бы он был потребителем. Это позволит им подходить к коду с большей осторожностью и вниманием, чтобы улучшить взаимодействие с пользователем и свести к минимуму любые ошибки кэширования.

Неожиданные коды ошибок

Сообщения об ошибках API указывают разработчикам правильное направление всякий раз, когда в коде обнаруживаются несоответствия. Однако иногда возникают неожиданные коды ошибок и отсутствует достаточная информация о том, что пошло не так, что заставляет разработчика пытаться понять это самостоятельно.

Поставщикам API важно оптимизировать процесс разработки, примером чего является Twilio, коммуникационная платформа. Реализации Twilio предоставляют ссылки в сообщениях об ошибках, чтобы указать разработчику правильное направление для устранения любой ошибки, которая могла быть допущена в коде. Сохраняя краткость и предоставляя больше полезной информации для разработчика, можно быстро исправить любую ошибку.

Использование неправильного метода HTTP

Очень часто разработчики используют неправильный метод HTTP. Часто это можно списать на плохую документацию, но инструменты также могут создавать препятствия, если разработчик не внимателен. Например, в ситуации, когда разработчик хочет создать GET-запрос с телом запроса, лучше всего сделать curl-запрос с параметром -d и не использовать `-XGET`флаг, который по умолчанию будет автоматически POST и включать `Content-Type: application/x-www-form-urlencoded`заголовок.

В других случаях мы можем впасть в прошлые предположения и использовать неправильный метод. Например, API Runscope применяет POST при создании новых ресурсов, таких как этапы тестирования или среды, и PUT при их изменении. Но API Stripe использует методы POST при создании и обновлении объектов.
Независимо от того, какой подход выберет разработчик, важно быть последовательным во всем API и иметь правильные и актуальные документы, чтобы пользователи не столкнулись с этой ошибкой.

Отправка неверных учетных данных для авторизации

Если запрос не выполняется, разработчику важно убедиться, что он использует правильное слово в своем коде. Например, API, которые реализуют OAuth 2, обычно требуют, чтобы разработчик включал заголовок «Авторизация» для каждого запроса. Однако это часто путают с «Аутентификацией». При использовании базовой HTTP-аутентификации также важно уделять пристальное внимание синтаксису и грамматике значения заголовка.

Форма следующая:

Авторизация: Basic base64_encode (имя пользователя: пароль)

Распространенные ошибки включают в себя забывание префикса «Basic» (обратите внимание на пробел перед кавычками), некодирование имени пользователя и пароля или пропуск двоеточия между ними. Если поставщику API требуется только имя пользователя без пароля (например, Stripe, где ключ API — это имя пользователя), двоеточие после имени пользователя необходимо, даже если пароль отсутствует.

Не указан заголовок Content-Type или Accept

Заголовки Accept и Content-Type согласовывают тип информации, которая будет отправлена ​​или получена между клиентом и сервером. Некоторые API будут принимать запросы, которые не содержат ни одного из этих заголовков и просто используют общий формат по умолчанию.

Однако другие API могут возвращать ошибку 403, если вы явно не указываете значение заголовка Accept, и вам потребуется включать эти заголовки в запросы. Это предупреждает сервер о том, какую информацию отправляет клиент, а также о том, в каком формате следует ожидать получения.

API, возвращающие недопустимый тип контента при возникновении ошибки

Для поставщиков API некоторые платформы и веб-серверы по умолчанию используют HTML. Поэтому, если разработчик создает API, который не имеет права возвращать HTML, важно проверить ответ на ошибку по умолчанию.

Еще один аспект, на который следует обратить внимание, — это сетка маршрутизации или балансировщик нагрузки, который находится перед вашим API. Например, если перед вашим API находится экземпляр nginx, который обнаруживает тайм-аут запроса или другую ошибку, он может вернуть HTML-ошибку еще до того, как ваши экземпляры API получат возможность получить информацию о том, что происходит.

Неудача в командном общении

В любой компании отсутствие связи между командами может привести к каскаду ошибок и контролю ущерба. Например, если команда разработчиков не уведомит группу поддержки об изменении типа, группа поддержки затем рассеет ошибочную информацию и, следовательно, нанесет ущерб пользовательскому опыту. Точно так же, если команда UX не сообщит об изменении интерфейса команде разработчиков, это может привести к нарушению функциональности веб-сайта, а API будет в значительной степени недоступен.

Выход из этой ситуации прост – общение и командная работа. Когда план составляется на этапе разработки плана, лучше всего придерживаться его и уведомлять соответствующие группы о каждой вносимой поправке.

Это некоторые из наиболее распространенных ошибок, которые могут возникнуть в API. Они могут остаться незамеченными и привести к увеличению времени, затрачиваемого на устранение неполадок и отладку. Но с помощью вышеперечисленных указателей в сочетании с более высоким уровнем осознания и внимания к деталям этих ошибок можно избежать.