REST или GraphQL — что выбрать для нашей задачи?
В восьми случаях из десяти берём REST: он проще для партнёров, понятен любому разработчику и легко кэшируется. GraphQL выигрывает, когда у потребителей очень разные запросы — например, мобильное приложение тянет одним запросом данные из пяти разделов, а сайту нужны те же данные маленькими порциями: экономится трафик и число обращений. Бывает и гибрид: REST для партнёров и обмена с 1С, GraphQL для приложения. GraphQL дороже примерно на 15–20% и на 3–5 дней длиннее по сроку — поэтому предлагаем его только там, где он реально окупается.
Выдержит ли API нагрузку, если завтра всё вырастет в три раза?
Перед сдачей прогоняем сценарий на трёхкратном пике от вашей текущей нагрузки: например, 30 запросов в секунду при сегодняшних 10. Смотрим время ответа на 95-м процентиле (цель — до 300 мс на типовом запросе) и долю ошибок. Если база не держит — видно сразу, и лечится это кэшем в Redis и индексами, а не покупкой нового сервера. Хорошая новость: при правильной архитектуре API на Laravel, FastAPI, Node.js или Go спокойно держит сотни запросов в секунду на одном сервере — узким местом почти всегда оказывается база данных, а не код.
Что будет после запуска — кто поддерживает API?
Первые 30 дней исправляем ошибки бесплатно и отвечаем на вопросы ваших и партнёрских разработчиков. Дальше — по желанию: договор поддержки от 15 000 ₽ в месяц, туда входят контроль доступности, разбор логов, обновления и 3 часа доработок. Если API стабилен и вопросов нет, платить не обязательно: код, документация и доступы у вас, менять и развивать можно без нас. Работа по факту — 2 500 ₽ в час, минимальный блок 5 часов.
Совместимо ли это с моим стеком — 1С, CRM, внутренняя система?
Совместимо, если у системы есть хоть какой-то программный интерфейс: REST или SOAP у 1С, API у amoCRM, Битрикс24, RetailCRM и МойСклад, выгрузки и доступ к базе у старых решений. Сами работаем только на Laravel: API проектируем как часть сайта или отдельным сервисом, а не как надстройку над чужой платформой. Если готового API нет, пишем адаптер или работаем через промежуточную базу. Единственный случай, когда скажем «нет»: внутренняя система на Access или FoxPro, к которой нет ни разработчика, ни прямого доступа к данным. Тогда сначала придётся навести порядок в ней — это отдельный проект, и мы честно говорим об этом до подписания договора.
Кто пишет документацию к API?
Мы. Это часть проекта, а не отдельная услуга за доплату. Документация двух видов: машинная — спецификация OpenAPI 3.1, из которой автоматически собирается Swagger UI на отдельном поддомене вашего сайта, и человеческая — «как получить токен, как оформить заказ, что делать при ошибке 422», с примерами на PHP, Python и JavaScript. Обновляем документацию в тот же день, что и код: если ответ API разошёлся со спецификацией, сборка падает и мы узнаём об этом раньше партнёра.
Партнёр просит изменить формат данных — что делать?
Сначала смотрим, ломает ли это других потребителей. Добавить новое поле или новый необязательный параметр — выпускаем в текущей версии, никто ничего не замечает, срок 1–2 дня. Переименовать поле, поменять тип или убрать метод — только в новой версии /v2/, старую поддерживаем ещё 3–6 месяцев и предупреждаем всех, кто ей пользуется: в отчёте видно каждого. Такое изменение бесплатным не будет, это новая задача: оценка от 10 000 ₽, срок 2–5 рабочих дней.
Сколько стоит поддержка API?
От 15 000 ₽ в месяц: доступность, мониторинг, разбор инцидентов и 3 часа доработок. На практике у большинства клиентов уходит 2–4 часа в месяц. Если нужны только правки по факту — 2 500 ₽ в час, минимальный блок 5 часов. В первые 30 дней после запуска любые ошибки и вопросы по контракту закрываем бесплатно. Отдельно скажем, если поддержка вам не нужна вовсе: у стабильного API с хорошей документацией нагрузка на изменения близка к нулю.
