REST API
С REST API работаю с двух сторон. Разработкой backend API занимаюсь примерно с 2015 года, а взаимодействовать со сторонними сервисами начал еще раньше. За это время накопился приличный опыт - и в проектировании собственных API, и в интеграции с чужими.
Спецификация REST оставляет некоторые вопросы открытыми, и разные разработчики могут по-разному понимать, как правильно делать те или иные вещи. Чтобы для себя "разложить по полочкам", читал множество статей на эту тему. В итоге сформировалось понимание, каких принципов стоит придерживаться: правильные HTTP методы и статус-коды, нормальный нейминг эндпоинтов, версионирование, stateless, кеширование.
Про HATEOAS знаю, но на практике большинство компаний его не реализуют (разве что для ссылок пагинации). Думаю, это связано с неоправданной дополнительной сложностью, да и, прямо скажем, с отсутствием очевидных преимуществ в большинстве случаев. Проще обойтись без него.
Где применял
Рабочие проекты
-
2021-2024_-_Morizo
- Разработка и поддержка API для админ-панели Mosreg CMS
- Разработка REST API для внутренних сервисов компании
- Интеграция с внешними API: полнотекстовый поиск, сбор обращений граждан, баг-трекинг и др.
-
2018-2019_-_BTrud
- Спроектировал и разработал REST API для онлайн-сервиса по поиску вакансий и резюме
- Покрыл API автотестами на 100%, написал подробную документацию
-
2016-2017_-_Appwilio
- Разработка и поддержка REST API для мобильного приложения (США)
- Интеграция с API для конвертации валют (несколько взаимозаменяемых источников)
-
2016-2016_-_DSE
- Разработка интеграции с API аппаратного контроля доступа
- Поддержка backend системы управления мероприятиями для университетов США
-
2015-2016_-_TRM
- Разработал REST API для туристического портала с нуля
- Покрыл тестами API. Более чем 2000 интеграционных тестов
Личные проекты
- Content_Store - делал полноценный REST API для сервиса сохранения контента. Спроектировал так, чтобы работал с разными клиентами - web и Android
- Inboxly - backend API для агрегатора RSS/Atom фидов. Выделил в отдельный компонент с четкой API спецификацией, чтобы клиентское приложение можно было переписать независимо
- WantUs - интегрировался с API ВКонтакте для мониторинга сообщений в сообществах
Open-source пакеты
Написал несколько PHP-клиентов для работы с API разных сервисов:
- Vk_Client - клиент для работы с API ВКонтакте
- Laravel_Vk_Requester - Laravel-пакет для обработки запросов от VK
- Content_Store / content-fetcher - инструмент для получения контента через API
- Php_Client - набор клиентов для различных сервисов на базе библиотеки Saloon:
- php-client/openai - для работы с ChatGPT и совместимыми API
- php-client/ollama - для работы с локальными LLM-моделями
- php-client/tailscale - для управления VPN-сетью
- php-client/keenetic - для управления роутером
- php-client/syncthing - для управления синхронизацией файлов
Документирование
Для документирования API использовал разные инструменты. В ранних проектах (TRM, BTrud) работал с Postman - делал коллекции запросов и документацию там. В более поздних проектах, например в Content Store, перешел на OpenAPI (Swagger) - удобно для автогенерации документации и валидации.
Что еще делал
Со всеми типичными задачами при разработке API сталкивался: аутентификация (токены, OAuth, JWT), пагинация, фильтрация и сортировка, rate limiting, валидация входящих данных, обработка ошибок. В общем, стандартный набор, который нужен в любом нормальном API.