Home/ Questions/Q 7549647
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-30T09:59:54+00:00

For example, day, in a somewhat REST-oriented environment, a request comes in for an

  • 0

For example, day, in a somewhat REST-oriented environment, a request comes in for an object that doesn’t exist, like:

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

Is there anything wrong with sending back a 404 response who’s body is the same as a a different page? For example, responding like:

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

Does it make any sense to do this? Will this cause any problems with certain browsers? Is it confusing to the user? Or is this perfectly fine to do?

Along these same lines, I would have the content of the 404 response match the request’s accept headers as best I could. (ie. abide by content negotiation with the user agent)

For example, a xml or json request would get something along the lines of a simple error message and something that says “look here for similar things”, while an html request would get an HTML page that has the error message as well as the content of the list page (as I indicated above)

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I think it depends on how the Restful web services are being consumed. If I’m programmatically consuming the web service from a different application, then I would want the status code together and a plain text message instead of a message decorated with HTML tags. I mean, say for example, it doesn’t make sense to return a bloated 404 content if your user makes the web service call using Curl because the message will not be readable to them.

    You could have different “consumes” for each restful webservice. If it’s an XML request, then you return 404 and a plain text message. Otherwise, you return the error page content.

    • 0