2010-07-31 4 views
3

У меня есть веб-сервер, который обновляет свои данные раз в минуту и ​​хочет сделать эти данные доступными для клиентов всех типов. Чтобы уменьшить пропускную способность, я настроил PHP-скрипт для поддержки условных GET, используя IF-MODIFIED-SINCE и/или IF-NONE-MATCH. Идея состоит в том, что клиенты могут опросить каждые 30 секунд и тем самым быть уверены, что они ничего не пропустят, но также не получат дубликаты данных.Как опросить обновления с помощью JSONP?

Все это отлично подходит для большинства типов клиентов, и я проверил, что он работает с клиентами, поддерживающими стандартную условную семантику GET HTTP.

Но она не работает с JavaScript, поскольку JSONP вставляет < сценария > тега в DOM и позволяет браузер обрабатывать вещи - и нет никакой поддержки (по крайней мере, ни один, что я знаю) для условного GETs в < скрипт > теги.

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

http://api.mydomain.com/script.php?fmt=json&callback=jscallback&etag=ab79bc65e 

Если ETag данных не соответствует переданному ETag, то я отправить новые данные.

Это все работает хорошо и было удивительно легко кодировать с помощью jQuery. Моя дилемма, хотя это то, что нужно делать, если спички etag. Я вижу два варианта:

  1. возвращающие HTTP 304 (Not Modified)
  2. Вернуть HTTP 200 (OK), но возвращаемые данные, содержащие только информацию заголовка (дата изменения, ETag и т.д.) и нет фактических данных.

Если я делаю первый, то код клиента JavaScript значительно упрощается. Кажется, что браузер работает нормально, если он получает ответ 304 на введенный сценарий < >. Но ... что-то меня беспокоит об этом решении. Я не знаю, что это такое, но похоже, что я зависим от поведения, которое может быть специфичным для браузера. Некоторый браузер может решить сообщить об ошибке, если он получит сообщение 304.

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

Итак, на мой вопрос. Если вы пишете клиент JavaScript для получения этих данных, что бы вы предпочли? Тихая неудача, которая никогда не вызывает ваш «успешный» обратный вызов? Или возврат «успеха», в котором нет данных (помимо статуса)? Третий вариант?

ответ

2

Отсутствие обсуждения от других, я пошел с моей кишкой и реализовал второй вариант. Веб-сервер возвращает HTTP 200, а данные содержат код состояния «Не изменен» вместе с информацией заголовка, но без записей. Это делает JavaScript немного сложнее, но не позволяет мне зависать от недокументированного поведения.