Можно ли направлять запросы в разные приложения через Content-Type?

Question

Можно ли направлять запросы в разные приложения через Content-Type?

Я разрабатываю JSON API, и я хотел бы создать версию API с использованием какого-либо согласования контента. В настоящее время я планирую использовать Vendor MIME Types для этого.

Хотя я определенно могу сделать это на уровне приложений, я думаю, что было бы лучше, чтобы это происходило на уровне HTTP-сервера. Это возможно с Apache или nginx?

Тип контента будет выглядеть примерно так: application/vnd.vendorname-v1+jsonили возможно используя параметры: application/vnd.vendorname+json;v=1

4

linux apache-2.2 nginx http-headers

Источник

Adam Lassek 13 июл '11 в 20:12

3 ответа

Другие вопросы по тегам linux apache-2.2 nginx http-headers

Alexander Azarov 14 июл '11 в 07:38 2011-07-14 07:38 · Answer 1 · 2011-07-14 07:38

Идиоматический подход Nginx к решению подобных проблем заключается в map, Пожалуйста, смотрите мой ответ на StackOverflow.

По сути, вы определяете map в http раздел

map $any_variable $my_upstream {
  # Default value:
  default upstream1;

  # Exact match:
  application/vnd.vendorname+json;v=1 upstream2;

  # Regexp:
  ~^application.*vnd.vendorname-v1\+json upstream3;
}

Вы можете смешивать точные совпадения и регулярные выражения на одной карте.

Тогда вы просто используете $my_upstream в тебе server или же location раздел (ы):

location / {
  proxy_pass http://$my_upstream$uri;
}

Nginx оценивает переменные карты лениво, только один раз (для каждого запроса) и при их использовании.

womble 13 июл '11 в 23:44 2011-07-13 23:44 · Answer 2 · 2011-07-13 23:44

Конечно; апача mod_rewrite может сделать это с небольшим RewriteCondхотя я немного ржавый, чтобы привести пример с макушки головы. Однако в nginx это выглядело бы примерно так (при условии, что вы определили два восходящих потока: один для вашего jsonapp, а другой для... otherstuff):

if ($content_type = application/vnd.vendorname-v1+json) {
    proxy_pass http://jsonapp/
    break;
}
proxy_pass http://otherstuff/

Matt 14 июл '11 в 21:12 2011-07-14 21:12 · Answer 3 · 2011-07-14 21:12

Я собираюсь пойти против того, что предложили другие.

Я думаю, что очень плохая идея полагаться на управление версиями вашего JSON API с HTTP-сервера. HTTP-сервер ничего не знает о API, который вы разрабатываете. Это похоже на определение версии Linux в текстовом файле, а не встраивание ее в исходный код ядра. Это делает обновления более сложными.

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

Не зная много о том, что вы делаете, должен быть способ сделать его доступным с помощью вашего языка сценариев (Вы используете язык сценариев или это пользовательский JSON-ответчик?). то есть как глобальная переменная, которая доступна в JavaScript. Или возвращая его по запросу, запрос JSON для получения версии API. Или всегда отправлять его во всех ответах JSON в начале ответа. Это очень мало текста в конце концов.

Используйте подход KISS, и вы не пожалеете об этом.