Что-то не так с отправкой другого контента вместе с ошибкой 404?

Question

Например, днем, в несколько REST-ориентированной среде, приходит запрос на объект, который не существует, например:

GET http://example.com/thing/5

Что-то не так с отправкой ответа 404, чье тело совпадает с другой страницей? Например, отвечая как:

404 body: [content from "http://example.com/thing/" which is a list of things]

Есть ли смысл делать это? Это вызовет какие-либо проблемы с определенными браузерами? Это смущает пользователя? Или это прекрасно?

В соответствии с этими же строками, я бы хотел, чтобы содержимое ответа 404 соответствовало заголовкам принятия запроса, как мог. (т. е. соблюдать согласование содержимого с пользовательским агентом)

Например, запрос xml или json может получить что-то похожее на простое сообщение об ошибке и что-то вроде «ищите здесь похожие вещи», в то время как запрос html получит страницу HTML, которая также содержит сообщение об ошибке в качестве содержимого страницы списка (как я указал выше)

Answer 1

Я думаю, это зависит от того, как используются веб-сервисы Restful.Если я программно использую веб-сервис из другого приложения, то я хотел бы, чтобы код состояния вместе и текстовое сообщение вместо сообщения, украшенного тегами HTML.Я имею в виду, скажем, например, что нет смысла возвращать раздутый контент 404, если ваш пользователь выполняет вызов веб-службы, используя Curl, потому что сообщение не будет для них доступно для чтения.

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

Answer 2

Я не вижу в этом ничего плохого.В нашем веб-сервисе мы всегда отправляем обратно объект ошибки json, который включает в себя трассировки стека и другие подробности об ответе.Даже на обычном веб-сервере вы получаете по крайней мере текст, который можно отобразить в браузере, говоря, что вы получили ответ 404.