Какой способ RESTful проверить, может ли клиент получить доступ к ресурсу?
Я пытаюсь определить наилучшую практику REST API для определения того, может ли клиент получить доступ к определенному ресурсу. Два быстрых примера сценариев:
Служба поиска в телефонном справочнике. Клиент ищет номер телефона, получая доступ, например.GET http://host/directoryEntries/numbers/12345
... где 12345— номер телефона, который необходимо найти в каталоге.Если он существует, он вернет такую информацию, как имя и адрес человека, чей это номер телефона.
Служба смены формата видео. Клиент отправляет видео в одном формате, например.POST http://host/videos/
... и получает «идентификатор GUID видео», созданный сервером для этого видео. Затем клиент проверяет, например.GET http://host/videos/[GUID]/flv
... для получения видео, преобразованного в формат FLV, если существует преобразованная версия.
Вы заметите, что в обоих вышеприведенных случаях я не упомянул, что должно произойти, если проверяемый ресурс несуществует. Вот мой вопрос. Я читал в различныхдругихместах, что правильный способ RESTful для клиента проверить, существует ли здесь ресурс, — это вызвать HEAD(или, может быть, GET) для ресурса, и если ресурс не существует, следует ожидать ответа 404. Это было бы хорошо, за исключением того, что ответ 404 широко считается «ошибкой»; в спецификации HTTP/1.1указано, что класс кода состояния 4xx предназначен для случаев, когда клиент «кажется, что допустил ошибку». Но ждать; в этих примерах клиент точно не ошибся. Он ожидает, что он может получить ответ 404 (или другие; может быть 403, если он не авторизован для доступа к этому ресурсу), и он не сделал никакой ошибки при запросе ресурса. 404 не предназначен для указания на «состояние ошибки», это просто информация — «этого не существует».
И браузеры ведут себя, как предполагает спецификация HTTP, как будто ответ 404 является настоящей ошибкой.И Google Chrome, и консоль Firebug выводят большое красное сообщение об ошибке «404 Not Found» в консоль Javascript каждый раз, когда 404 получен запросом XHR, независимо от того, был ли он обработан обработчиком ошибок или нет, и нет способ отключить его. Это не проблема для пользователя, так как он не видит консоль, но как разработчик я не хочу видеть кучу ошибок 404 (или 403 и т.д.) в моей консоли JS, когда я прекрасно знаю хорошо, что это не ошибки, а информация, обрабатываемая моим кодом Javascript. Это линейный шум. Во втором примере, который я привел, шум линии доведен до предела, потому что клиент, вероятно, будет опрашивать сервер для этого /flv, так как компиляция может занять некоторое время, и клиент хочет отобразить «не еще не скомпилировано», пока не получит не-404. Каждую секунду или две в консоли JS может появляться ошибка 404.
Итак, это лучший или наиболее правильный способ, который мы имеем с REST для проверки существования ресурса? Как нам обойти линейный шум в консоли JS? Вполне можно предположить, что в моем втором примере можно было бы запросить другой URI для проверки статусакомпиляции, например:GET http://host/videos/[GUID]/ compileStatus
... однако мне кажется, что это немного нарушает принцип REST; вы не используете HTTP в полном объеме и обращаете внимание на заголовки HTTP, а вместо этого создаете свой собственный протокол, посредством которого вы возвращаете информацию в теле, сообщающую вам, что вы хотите знать, и всегда возвращаете HTTP 200, чтобы закрыть браузер .Это было серьезной критикой SOAP — он пытается «обойти» HTTP, а не использовать его в полной мере. По этому принципу, почему вообще нужно возвращать код состояния 404? Вы всегда можете вернуть 200 - конечно,200 указывает, что информация о статусе ресурса доступна, и информация о статусе сообщает вам то, что вы действительно хотели знать — ресурс не найден. Конечно, RESTful должен возвращать код состояния 404.
Этот механизм кажется еще более надуманным, если мы применим его к первому из приведенных выше примеров; клиент, возможно, запросит:GET http://host/directoryEntries/numberStatuses/12345
... и, конечно же, получит 200; информация о статусе номера 12345существует и сообщает вам... что этот номер не найден в справочнике. Это будет означать, что ЛЮБОЙ запрошенный номер будет «200 OK», даже если он может не существовать — кажется ли это хорошим интерфейсом REST?
Я что-то пропустил? Есть ли лучший способ определить, существует ли ресурс RESTful, или, возможно, HTTP должен быть обновлен, чтобы указать, что коды состояния, отличные от 2xx, не обязательно должны считаться «ошибками», а являются просто информацией? Должны ли браузеры быть настроены так, чтобы они не всегда выводили ответы о статусе, отличные от 2xx, как «ошибки» в консоли JS?
ПС. Если вы дочитали до этого места, спасибо. ;-)