2013-06-24 3 views
0

Я перепроектирую свое приложение предыдущего века (которое работает очень хорошо, заметьте), и возможность начать новую работу, я изучил несколько аспектов. Этот вопрос повторяется. управления версиями.Создание собственного пользовательского заголовка для управления версиями REST API

Приложение действительно представляет собой набор приложений для передачи данных, которые предоставляют ресурсы - запрос - это http, а ответ - JSON. Теперь я хочу изменить один из ответов. После прочтения, я решил, что не реализовать управление версиями через URI или query_string. Вместо этого, как сообщается в Best practices for API versioning?, особенно второй ответ (нет способа, которым Stackoverflow ссылается на конкретный ответ?), Я использую заголовки. Однако, вместо того, чтобы использовать Accept: application/vnd.company.myapp.customer-v3+json Я использую

Accept: application/json 
X-Requested-With: XMLHttpRequest 
X-Version: 2 

На стороне сервера я в состоянии проверить значение для X-Version. Если он не существует, запрос использует новейший API. Это X-Version действительно существует, тогда используется версия запроса. Вышеизложенное работает отлично.

Мой вопрос - любые ошибки, о которых я должен знать? Особенно так как я вытащил это X-Version из моего приклада. Насколько я знаю, это не официально санкционированный заголовок.

Обновление: Drats! даже перед публикацией этого я прочитал Custom HTTP headers : naming conventions, и, похоже, я не должен использовать префикс X-. Тем не менее, тогда есть вероятность того, что мой доморощенный заголовок противоречит существующему стандарту, если я не буду сначала проявлять должную осмотрительность. Мысли?

+0

Почему вы решили не использовать управление версиями медиа-типа? Какую «область действия» имеет ваша X-версия (или MyCompany-Version)? – Pete

+0

честно говоря, я не использовал версии управления версиями носителей, потому что я не знаю, что это такое и почему я должен его использовать. Я не могу ответить на второй вопрос, потому что я не понимаю смысла «сферы действия» в контексте вопроса. Возможно, вы имеете в виду то, что означает 'X-Version'. В частности, это относится к запрашиваемому ресурсу. Другими словами, запрос говорит: «Получите мне ресурс в конце этого URI, используя API версии 2, который применим ** только ** к этому ресурсу». Другими словами, другие ресурсы могут продолжать использовать свои собственные версии API. – punkish

ответ

0

Существует лот дебатов вокруг «правильного» способа сделать это. Для некоторых мыслей высоких уровня, проверить mnot лет: WEB API VERSIONING SMACKDOWN

Для обсуждения очень глубокий, проверить это сообщение к API-Craft: https://groups.google.com/forum/#!topic/api-craft/E8MBkzirdcw

Лично я предпочитаю сочетание типа медиа-версии, а также ссылку отношение версия, для достижения этого.

+0

Отличные чтения, те ссылки, которые вы предоставили. Однако мне все еще нужна определенная ясность. Пример: У меня есть URI, который возвращает JSON, который уже используется приложением iOS. Теперь я хочу изменить структуру возвращаемого JSON, но я не хочу, чтобы существующее приложение (установленное на лорде знает, сколько устройств) сломалось. Использование 'X-Version' работает. URI не изменяется, но разные версии приложений могут получать правильные данные. Кроме того, поскольку управление версиями на URI, приложение может использовать URI разных версий. Каким образом сопоставление версий медиа-типа и ссылок связано с таким сценарием? – punkish

+0

Вы пытаетесь внести изменения в формат? Или добавление? – Pete

+0

В этом случае изменение может не сломать что-либо, но это мое предположение. Только разработчик приложений точно знал бы. Я намерен придерживаться [семантического версирования] (http://semver.org), но я должен разработать устойчивый принцип проектирования API. Я не могу догадаться, будут ли мои изменения нарушать приложения других людей. То, что я могу сделать, это предоставить некоторую версию управления версиями, чтобы они могли использовать любую желаемую версию. – punkish