Я проектирование мой API, и я указать дополнительную версию API в URLЕсли я укажу версию API в URL-адресе, должен ли я предложить ее также в заголовке?
GET /Issuer/{certificate-name}/versions?api-version=2016-10-01[&maxresults]
Должен ли я также иметь один, указанный в заголовке HTTP (гибкости)?
Что делать, если есть конфликт между двумя подходами?
Нет очевидного преимущества, позволяющего вводить версию API из двух разных методов ввода (querystring и Header). Однако недостатком здесь является разрешение конфликтов, если оба они указаны клиентом.
Нет правильного или неправильного способа указания версии API, будь то в заголовке или в строке запроса. Но имейте в виду, что для URL-адресов требуется синтаксический анализ, в основном это делается по структуре, но все же вычислительный ресурс, который вы тратите на анализ URL-адреса, чтобы извлечь значение.
I ()) предпочитают использовать заголовок простоты. Кроме того, он чувствует себя более чистым, чтобы URL-адрес был адресован только для указания функции/намерения клиента.
Какова его ценность для того, чтобы начать с (всякая клиентская * некоторая * версия API)? Какова ценность наличия двух отдельных способов его определения? – sisyphus
Никакое указанное значение не соответствует последней версии. Значение двух разных выражений состоит в том, чтобы позволить REST-идиологическим/фундаменталистским клиентам получить требуемую функциональность. В этом смысле я ISV, и я взвешиваю необходимость учитывать обе перспективы. @sisyphus – LamonteCristo
Я считаю, что версия в параметрах запроса очень полезна, особенно для целей тестирования в браузере. Мне нравится идея иметь возможность просто «щелкнуть» ссылку, чтобы показать мне, как API отвечает, используя мой любимый браузер и его расширение JSON. В случае конфликтов вы можете либо вернуть 400 с ошибкой, указывающей причину, либо дать приоритет одному из них (я бы дал параметру queryParameter больше значения, чем заголовок, потому что он, вероятно, будет использоваться для переопределения любой существующей конфигурации в случай испытания). Однако будьте осторожны с версией API версии vs Resource Representation. –