PHP Lang
  1. PHP Lang
  3. PHP и пользовательские заголовки HTTP, плохая практика?
Intereting Posts
Рекомендации: безопасный метод хранения паролей в таблице? DOMDocument: игнорировать повторяющиеся идентификаторы элементов Возвращаемое значение для браузера, но все еще обрабатывается в PHP JSON создает форму для поиска диапазона дат с использованием значения «datetime» PDO с INSERT INTO через подготовленные заявления PHP конвертирует hex в байт Наложение div div над другим div, с jQuery, если возможно Как создать динамические субдомены в кодеигниторе с помощью htaccess Удаление повторяющихся строк из таблицы MySql PHP – Как объединить массивы внутри массива Как запретить MySQL обновлять столбец с пустой строкой? Странная неожиданная ошибка T_STRING От одного до многих отношений и добавление / изменение формы в SonataAdmin и Symfony2 Возможно ли PhpStorm автоматически заполнять поле БД в виде строки в файле PHP? импортировать данные из csv в mysql, используя cakephp

PHP и пользовательские заголовки HTTP, плохая практика?

У меня есть пользовательская реализация RESTful API для PHP-приложения, которое возвращает данные json, и для того, чтобы сообщить о статусе операции, то есть были ли сбои в запросе, я устанавливаю пользовательский заголовок HTTP с крошечный) json объект как строка. Это хорошо работает, так как я могу отправлять ответы и легко извлекать их на стороне клиента, не испортив фактические данные.

Вопрос в том, есть ли какие-то недостатки, которые я, возможно, не понял, используя этот метод? Похоже, что приложения не очень распространены для создания пользовательских заголовков HTTP, поэтому мне интересно, насколько плохо это происходит или плохой «вкус».

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

  1. Заголовки должны быть уникальными для вашего приложения. Не только сейчас, но и навсегда. Вы должны убедиться, что вы их префикс, например, X-MyApplication-Foo: Bar . В противном случае это может привести к конфликтам.
  2. Брандмауэры иногда (редко) немного переусердствуют с фильтрацией неизвестных HTTP-заголовков. Это не должно быть проблемой, но это нужно иметь в виду.
  3. У более старых браузеров меньше ограничений на размер полей заголовков, чем у современных браузеров, поэтому вам нужно протестировать столько, сколько вы можете получить.

Есть ли причина, по которой вы не можете использовать стандартные коды ошибок HTTP? Я понимаю, что вам может понадобиться предоставить трассировки стека или другую полезную информацию для отладки, но в случае ошибки не вы бы просто вернули бы кусок JSON, содержащий информацию об ошибках, а не обычные данные «результата» JSON? Вы можете легко обнаружить разницу на основе кода ошибки HTTP и обрабатывать два случая по-разному.

Причина, по которой меня беспокоит предложенный вами подход, заключается в том, что заголовки используются для изменения или поведения браузера – они не предназначены для механизма хранения данных.

Пример псевдокода: 

 switch(httpResponseCode) { case 200: parseResult(json); break; case 403: parseForbidden(json); break; case 500: parseServerError(json); break; default: // bad response code, handle appropriately }