Я бы не стал ничего менять в коде состояния, чтобы он был обратно совместим. Я бы добавил в ответ заголовок «Предупреждение»:
Warning: 299 - "Deprecated API"
Вы также можете указать «-» с «Агентом», который выдает предупреждение, и быть более явным в тексте предупреждения:
Warning: 299 api.blazingFrog.com "Deprecated API: use betterapi.blazingFrog.com instead. Old API maintained until 2015-06-02"
Заголовок предупреждения указан здесь: https://tools.ietf.org/html/rfc7234#section-5.5 . Код предупреждения 299 является общим, "Устарело" - нестандартным.
Вы должны указать своим клиентам API регистрировать предупреждения HTTP и отслеживать их.
Я никогда не использовал его до сих пор, но когда моя компания станет более зрелой в Rest API, я интегрирую его.
Изменить (2019-04-25): как отметил @Harry Wood, заголовок предупреждения находится в главе документации, связанной с кешированием. Однако RFC ясенWarnings can be used for other purposes, both cache-related and otherwise.
Если вы предпочитаете альтернативный метод, этот черновик https://tools.ietf.org/html/draft-dalal-deprecation-header-00 предлагает новый заголовок «Устарело».
Date
значения в том же сообщении, получатель ДОЛЖЕН исключить значение-предупреждения. . . до . . . используя сообщение ».