REST-обработка удаленных обратно совместимых функций

Как семантическое управление версиями определяет изменение версии, необходимое, когда функциональность удалена, но клиент не обязательно сломается?

Например, если у меня есть ресурс, который принимает параметр сортировки:

/person?sort=name

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


api rest versioning semantic-versioning
person smp7d    schedule 06.01.2016    source источник

Ответы (1)


arrow_upward
3
arrow_downward

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

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

person sisyphus    schedule 06.01.2016