Управление версиями API REST (только присваивают версию представлению, не самому ресурсу),

Как бы то ни было, я согласен с тобой, Мануэль. Вы можете увидеть мои рассуждения в этом вопросе Как вернуть REST URI

Есть много людей, которые, кажется, не согласны, но я бы не стал беспокоиться. То, как выглядит ваш url, на самом деле не имеет большого значения для вашего клиента, если вы уважаете ограничение гипертекста.

Я нахожу http://xxxx/v1/user/123. сбивчиво, так как это наводит на мысль о том, что там когда-нибудь будет более высокая апи-версия. например http://xxxx/v2/user/123

Это не означает, что - как бы вы ни обладали такой способностью в будущем.

Но в REST это не имеет смысла. условия, самой версией api является HTTP 1.0 или 1.1, который уже отправлен внутри HTTP-запроса.

Версия ВАШЕГО API и версия HTTP, которую вы используете для отправки запросов, не обязательно должны быть одинаковыми.

Можно также утверждать, что такая версия контент-переговоры могут быть частью УРТ внутри пути, но я нахожу его интуитивно понятно, потому что вы могли бы end-up с различными URI для одинаковый ресурс и должны поддерживать в какой-то момент перенаправляется.

Это нормально иметь версию в качестве параметра URI, как вы продемонстрировали.

http://xxx/user/123?v=1 -> для перма-ссылок/гиперссылок

Вы могли бы прослушать заголовок HTTP-запроса X-API-версии . Если заголовок существует, то сервер должен использовать эту версию API. Если заголовок отсутствует, сервер может использовать последнюю версию API.

> GET /user/123 HTTP/1.1
> Host: xxx
> X-API-Version: >=1.5.1, <2.0.0
> Accept: application/json
>

< HTTP/1.1 200 OK
< X-API-Version: 1.6.12
<
< { "user": { "id": 123, "name": "Bob Smith" } }
<

Использовать getRingerMode () метод в AudioManager.

AudioManager am = (AudioManager)getSystemService(Context.AUDIO_SERVICE);

switch (am.getRingerMode()) {
    case AudioManager.RINGER_MODE_SILENT:
        Log.i("MyApp","Silent mode");
        break;
    case AudioManager.RINGER_MODE_VIBRATE:
        Log.i("MyApp","Vibrate mode");
        break;
    case AudioManager.RINGER_MODE_NORMAL:
        Log.i("MyApp","Normal mode");
        break;
}

Вот текущий алгоритм сравнения версий Maven и его обсуждение . Если версии только растут, и все поля, кроме номера сборки, обновляются вручную, то это хорошо. Квалификаторы работают так: если один является префиксом другого, длиннее - старше. В противном случае их сравнивают по алфавиту. Используйте их для предварительных версий.

использование семантического управления версиями для выражения совместимости; major предназначен для изменений, не совместимых с обратной связью, minor для функций, совместимых с обратной связью, patch для bugfixes, совместимых с обратной связью. Документируйте его, чтобы пользователи библиотеки могли правильно выражать зависимости от библиотеки. Моментальные снимки автоматизированы и их не нужно увеличивать, за исключением первого моментального снимка после выпуска из-за способа сравнения префиксов.

Я согласен с тем, что вы не хотите видеть версии в URI ресурсов, представленных в вашем API. Это делает их не «крутыми.» Также соглашайтесь, что это представления, которые, скорее всего, изменятся.

Однако в этом случае возникает вопрос о том, что происходит при изменении содержимого определенного представления. Например, если ваше первоначальное представление frobnitz в JSON равно

{"x": "bam", "y": "hello"}

и вы хотите добавить поле «z», вы можете почувствовать, что клиент должен иметь некоторое представление о том, что мы сейчас находимся на версии 2 какой-то схемы данных.

Я не уверен в этом. Я думаю, что у вас есть несколько вариантов:

• Сделайте своих клиентов гибкими перед лицом мягко меняющихся представлений. В приведенном выше примере мы все еще создаем словарь JSON.
• Если необходимо, поместите версию в само представление (поле версии в этом примере). Таким образом вы фактически объявляете субпредставление внутри типа контента JSON. Я считаю, что это довольно ограниченно.
• Используйте собственные типы MIME и их версии: application/x-my-special-json1.0, application/x-my-special-json1.1. Это позволяет выполнять версию представлений независимо друг от друга. Опять же, с этим вы делаете значительный спрос на ваших клиентов, чтобы знать, что происходит.

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

Другой подход может заключаться в том, чтобы сказать, что «одно представление имеет несколько API»:

http://xxx/user/123/api/1.json

И если вы хотите, вы можете вернуть представление, используя последнюю версию API, запрашивая следующим образом:

http://xxx/user/123.json

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