Отправка настраиваемой информации об ошибках HTTP во Flash, JavaScript и т. Д.

Question

В настоящее время я разрабатываю REST API, и одна из его основных функций заключается в том, что он использует различные коды состояния HTTP для возврата информации о состоянии / ошибке, некоторые из которых могут быть расширенной информацией (например, если элемент не найден, некоторые другие подобные элементы), которые будут в теле ответа.

Это нормально, пока вы не доберетесь до «поврежденных» клиентов, таких как Flash и JavaScript, которые не могут получить доступ к телу ответа или заголовкам, если код состояния HTTP не соответствует 200 OK (даже созданный код успеха 201 может заставить Flash перестать думать, что это ошибка).

Итак, мой вопрос: существует ли стандартный способ, позволяющий клиенту этого типа запрашивать, чтобы все коды состояния были HTTP 200, и указывать код состояния real другим способом?

Одним из решений, о котором я думал, является использование шаблона заголовка HTTP Accept-* с использованием заголовка расширения X-Accept-Status, чтобы указать, какие коды состояния могут обрабатываться, например, Флэш отправит ...

X-Accept-Status: 200

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

X-HTTP-Status-Code: 404 Not Found

Все это выглядит немного ужасно и работает против протокола, но если у вас есть клиенты, которые не могут использовать свойство протокола, это неизбежно. Я просто ищу что-то вроде X-HTTP-Method-Override (это «стандартный» способ работы с протоколом для клиентов, которые не могут отправлять запросы PUT / DELETE), но для клиентов, которые не могут понять коды состояния.

Answer 1

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

я не думаю, что HTTP является обязательным ... все же, REST - хорошая идея, а REST полнота системы - мощное свойство ... так почему бы не использовать HTTP как тупой транспортный слой для REST полной системы?

это то, что вы делаете, хотя, по моему мнению, вы слишком сильно держитесь за HTTP и все это теоретически встроенные функции ... вам действительно нужно переносить информацию в коде состояния ?

не так сильно зависит от вашего транспортного протокола / уровня ... имейте в виду, как должен работать ваш сервис ... отделяйте семантику протокола от его реализации ... как на клиенте, так и на сервере ... ... абстрагируйте ваши REST коды полноты и статуса (сделайте их больше, чем просто целыми числами ... сделайте их перечислениями или объектами ... исключениями, почему бы и нет?) ...

и затем подключаемые протоколы / транспортные уровни по желанию ...

• сделать стандартную HTTP реализацию
• сделайте хакерский, используя решение, которое вы описали (что мне кажется вполне оправданным ... если люди используют технологии, не способные использовать стандарты, зачем вам слишком много искать решение, наиболее соответствующее стандартам)
• делайте все, что у вас есть время, и ваш сервер может делать, в двоичном виде, JSON, XML ... все, что кажется адекватным ...

две технические заметки:

1. флэш-плеер делает HTTP трафик через браузер ... и он просто не получает коды состояния из браузера ... ну, это зависит от браузера на самом деле ... спецификации говорят, что это не так работать для: «Netscape, Mozilla, Safari, Opera и Internet Explorer для Macintosh». ... так что IE для Windows должен работать? Хром? Я не знаю ... но я думаю, это не имеет значения, так как, очевидно, вы не можете полагаться на это ... о, и констатировать самое очевидное: JavaScript также делает HTTP над браузером, конечно ... такая же проблема здесь ...
2. для обоих это означает, что если вам удастся найти что-то вроде X-HTTP-Method-Override для ответа, встроенное в протокол, хороший браузер поймет это и будет соответственно перераспределять вещи, до решая, какую информацию передавать в JavaScript или сторонние плагины ... чтобы вы снова ничего не получили ... я думаю ...

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

Greetz

back2dos

Answer 2

Задержка ответа, но ...

Когда я реализовал API-интерфейс флэш-клиента в более ранней версии OpenRasta, у меня была X-ResponseLine, которая содержала код ответа и текст для каждого исходящего запроса.

Поскольку заголовки по умолчанию являются только общими заголовками, они не участвуют в кешировании, поэтому нет причин иметь в этом согласие / изменение.

Answer 3

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