API означает интерфейс прикладного программирования, концепция, которая применяется везде, от инструментов командной строки до корпоративного кода Java и веб-приложений Ruby on Rails. API - это способ программного взаимодействия с отдельным программным компонентом или ресурсом.
Если вы не пишете каждую строчку кода с нуля, вам придется взаимодействовать с внешними программными компонентами, каждый со своим собственным API. Даже если вы напишете что-то полностью с нуля, хорошо спроектированное программное приложение будет иметь внутренние API-интерфейсы, которые помогут организовать код и сделать компоненты более пригодными для повторного использования. И существует множество общедоступных API-интерфейсов, которые позволяют использовать функции, разработанные в других местах в Интернете.
Что такое API?
API определяется как спецификация возможных взаимодействий с программным компонентом. API определяет функции, которые не зависят от их соответствующих реализаций, что позволяет этим реализациям и определениям варьироваться без ущерба друг другу. Следовательно, хороший API упрощает разработку программы, предоставляя строительные блоки.
Когда разработчики создают код, они не часто начинают с нуля. API-интерфейсы позволяют разработчикам делать повторяющиеся, но сложные процессы многократно используемыми с помощью небольшого количества кода. Скорость, с которой API-интерфейсы позволяют разработчикам создавать приложения, имеет решающее значение для текущих темпов разработки приложений.
Разработчики теперь работают намного продуктивнее, чем раньше, когда им приходилось писать много кода с нуля. Благодаря API им не нужно изобретать велосипед каждый раз, когда они пишут новую программу. Вместо этого они могут сосредоточиться на уникальном предложении своих приложений, передавая на аутсорсинг все стандартные функции API.
Рекомендации и основные принципы API
Некоторые из описанных ниже руководящих принципов и основных принципов являются субъективными, но они необходимы в сегодняшней разработке API. Они обеспечивают фундаментальные преимущества и помогают оставаться на одном уровне с общеотраслевым внедрением передовых практик:
Словарь
Это относится к стандартным соглашениям об именах, которым следует следовать при именовании каждой конечной точки API. Они должны быть удобочитаемыми, простыми для понимания и соответствовать стандартам HTTP.
Контроль версий
Создавая версии, вы позволяете различным потребителям получать доступ к вашим опубликованным API в двух разных вариантах. Хотя управление версиями усложняет существующие API, они, тем не менее, помогают лучше управлять конечными точками API, тем самым обслуживая различных потребителей через разные среды. Есть два разных способа реализовать это:
- URL - например, api.myorg.com/v1/users.
- Accept Header - запрос конкретной версии через заголовок запроса / принятия
Поддержка нескольких типов мультимедиа
В любой момент времени данный объект или ресурс может иметь несколько представлений. Это необходимо для того, чтобы различные потребители могли запрашивать контент или ресурс так, как им хотелось бы. При этом нет необходимости поддерживать все типы носителей, а только те, которые требуются в зависимости от конкретных случаев использования.
Кэширование и контроль параллелизма
Кэширование повышает производительность, тем самым обеспечивая более быстрый доступ к часто используемым ресурсам и устраняя нагрузку на внутренние службы. Однако кэширование сопряжено с проблемой управления одновременным доступом. Следовательно, важно лучше управлять кешированием, используя такие стандарты HTTP, как:
- ETag - теги сущностей. Эквивалентно управлению версиями каждого объекта для обновлений
- Last-Modified - содержит метку времени последнего изменения.
Стандартные коды ответа
Эта ответственность лежит на владельцах бизнеса, поскольку она влияет на бизнес-потребности потребителей ваших API. Определение контракта должно содержать все возможные коды ошибок, которые могут возникнуть с каждым API.
- Придерживайтесь стандартных кодов ответа HTTP
- Включите как деловые сообщения, так и сообщения для разработчиков. Сообщения разработчика должны быть необязательными и содержать технические сообщения, в которых описаны методы отладки и устранения неполадок.
- По соображениям безопасности не раскрывайте слишком много информации о запросе (чтобы избежать подделки межсайтовых запросов).
- Лучше всего ограничить список возможных кодов ошибок, так как слишком много кодов ошибок приводят к хаосу.
Соображения безопасности
Это не требует подробных объяснений, поскольку требования безопасности являются основными потребностями любого приложения или API. Помните, что ваши API в основном общедоступны, поэтому приложите все усилия, чтобы защитить их. Платформы управления API (объясненные в последующем разделе) предоставляют механизмы безопасности; однако, как разработчик API, вы должны знать о текущих тенденциях и лучших отраслевых практиках, принятых для удовлетворения требований безопасности.
- Всегда использовать SSL
- API-интерфейсы не сохраняют состояние, поэтому избегайте управления сеансами / файлами cookie - аутентифицируйте каждый запрос
- Авторизация на основе ресурса, а не URL-адреса
- Код состояния HTTP 401 по сравнению с 403: некоторые могут предпочесть использовать код 401, а не 403, чтобы указать, что аутентификация или авторизация не удались.
- Следуйте рекомендациям, определенным в Open Web Application Security Project (OWASP) Threat Protection.
API становится все более важным в веб-разработке, а его популярность и использование за последние несколько лет росли в геометрической прогрессии. Надеюсь, в этой статье подробно описаны основные принципы API. Если есть дополнительные примечания, которые я не включил, укажите их в комментариях.
(SA)
