Я не согласен, это трудно поддерживать. Я разрабатываю и поддерживаю подобные системы ежедневно, и я работал над системами, в которых используется управление версиями URL, чтобы увидеть разницу.

Развиваемый api вначале требует значительных затрат на разработку, но затраты на добавление новых функций остаются неизменными как для клиента, так и для сервера. Эта архитектура сводит к минимуму энтропию программного обеспечения и позволяет клиенту и серверу развиваться независимо, им нужно только обсудить и согласовать протокол, а не URL-адреса или порядок обращений к серверу.

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

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

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

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