Кому может пригодиться данный пост:
- тому кто пытается разобраться как работает API в Контакте;
- имеет опыт работы с популярными CMS, здесь речь пойдет о Joomla;
- сильно ограничен во времени;
Fullstack-developer
Эта статья является переводом моей английской статьи которую можно прочитать здесь. Заранее извиняюсь за возможные неточности в компьютерной терминологии на русском языке.
Интерфейсы прикладного программирования или API отвечают за большую часть системной интеграции и функциональных компонентов современного вычислительного ландшафта как в потребительской, так и в корпоративной среде.
Правильно сконструированные безопасные API обеспечивают значительные преимущества при создании новой системы, интеграции с другими системами и на протяжении всего жизненного цикла приложения.
Основываясь на опыте автора при внедрении API для различных клиентов в финансовом, страховом, телекоммуникационном и государственном секторах, безопасность часто упускается из виду в пользу упрощенной реализации для конкретного поставщика/продукта, что затрудняет интеграцию и приводит к дополнительным расходам на поддержку и внедрение новых функций.
В этой статье рассматриваются методы проектирования безопасности API в нейтральной для продукта манере, чтобы помочь архитекторам планировать и создавать простые в работе и безопасные API.
Рекомендуемый подход — отделить безопасность API от его бизнес-функций и позволить бэкэнд-разработчикам сосредоточиться только на бизнес-функциях. Когда бизнес-логика для API готова, ее можно опубликовать с помощью общих компонентов безопасности, описанных в этой статье.
В этой статье не даются какие-либо рекомендации по конкретному продукту, но любая современная платформа безопасности/управления API сможет удовлетворить большинство предлагаемых требований, используя имеющиеся стандартные функции.
За 21 год существования в SuperJob разработали три версии реализации API для интеграций с бэкендом. Во время разработки последней они решили пересмотреть подход к версионированию. Сейчас в актуальной реализации порядка 379 эндпойнтов, более 900 моделей сущностей и 11 поддерживаемых мажорных версий. Когда проект развивается, вместе с ним меняются и требования к API, а значит неизбежно нарушение обратной совместимости.
Опытом решения этой проблемы поделился Антон Золотилин из SuperJob. Вы увидите самые распространенные решения проблемы версионирования web-API и подход, который реализовал у себя SuperJob. А в качестве бонуса узнаете, как это решение помогает значительно сократить рост затрат на тестирование версий с помощью Impact-анализа.
Kubernetes API развиваются и периодически обновляются. Когда готов улучшенный API на замену старому, старый удаляют. См. политику Kubernetes по удалению API.
Скоро будет удалено несколько API. Это беты, которые еще можно использовать в текущих версиях Kubernetes, но они уже deprecated. Им на смену придут обновленные стабильные версии API ("GA", General availability).
В Kubernetes 1.22 (релиз ожидается в августе 2021 года) будет удалено несколько deprecated API. На странице релиза Kubernetes 1.22 можно посмотреть его график.
Слой API любого приложения - один из важнейших программных компонентов системы. Это канал, который соединяет клиента с сервером (или один микросервис с другим), управляет бизнес-процессами и представляет сервисы, которые приносят пользу пользователям.
Общедоступный API, ориентированный на клиента, который делают открытым для конечных пользователей, сам по себе становится продуктом. Если он сломается, это подвергнет риску не только одно приложение, но и целую цепочку бизнес-процессов, построенных вокруг него.
Становится понятно, что важность тестирования API очевидна. Некоторые методологии и ресурсы помогают нам узнать КАК тестировать API - вы можете использовать ручное тестирование, автоматическое тестирование, тестовые среды, инструменты, библиотеки и фреймворки. Однако, независимо от того, чем вы будете пользоваться - Postman, supertest, pytest, JMeter, mocha, Jasmine, RestAssured или любыми другими инструментами - прежде чем открывать любой инструмент тестирования, вам необходимо определить, что тестировать...
Сегодняшний мир держится на интерфейсах прикладного программирования — API. С ними стало возможным получать данные и потреблять услуги через веб-приложения, мобильные приложения и устройства, подключенные к сети. Все чаще взаимодействие в интернете выполняются именно через API. Благодаря API появляются новые модели ведения бизнеса, а интернет стал универсальной бизнес-платформой.
API не имеет индустриальной привязки, компании из разных сфер экономики видят в их использовании ценность для своего бизнеса. В свою очередь, рынок программного обеспечения для управления API стремительно развивается, об этом свидетельствуют отчеты Gartner и Forrester.
Думаю, мы недостаточно говорим о будущем API. Я не помню ни одного хорошего обсуждения о том, что ждёт API в будущем. Вот совсем не припоминаю. Но если мы хорошенько подумаем об этом, то придём к выводу, что API в том виде, в каком мы понимаем сейчас — это далеко не конец игры. В этом виде API не будет оставаться вечно. Давайте попробуем заглянуть в будущее и ответить на вопрос, что случится с API в будущем.
Поднимите руку те, кто фронтенд разработчик в этом зале? Кто мобильный разработчик? Кто бэкенд разработчик?Бэкенд разработчиков большинство в этом зале сейчас, что радостно. Во-вторых, почти все проснулись. Чудесная новость.