docs(routing): add error handling section

[horvbalint]

🔗 Linked issue

❓ Type of change

• [x] 📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
• [ ] 🐞 Bug fix (a non-breaking change that fixes an issue)
• [ ] 👌 Enhancement (improving an existing functionality like performance)
• [ ] ✨ New feature (a non-breaking change that adds functionality)
• [ ] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• [ ] ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

While migrating some servers to Nitro (in Nuxt), I came across an odd behaviour that took some time to unveil. For some of the routes errors were handled correctly, while for others the client could not determine the error type. With some trial and error I figured out, that there is a difference between how an error is sent back to the client depening on which route directory the route is placed.

The routes/ dir uses a Content-Type of text/html, while the api/ dir application/json by default. In this PR I tried to clarify this in the docs, wich previously stated that the only difference is the /api/ prefix.

As a side note I would be very interested, in the reasoning behind this behaviour. I feel like it is quite footgun-y, while I don't see the benefits.

📝 Checklist

• [ ] I have linked an issue or discussion.
• [x] I have updated the documentation accordingly.

[horvbalint]

@pi0 Thanks for the quick response! I went to sleep sorry 😃

I tried to fix the docs according your comments. I found no appropriate place for this note in the current docs, so I created an 'Error handling' section in the routing guide (similar how it is in the H3 docs). Hopefully this is ok :)

Can you tell me the reasoning behind this route path based content type behaviour?

[pi0]

Thanks again for the PR and sorry for my late reply.

The reason is that when using tools like curl or HTTP clients like fetch (instead of directly) making request, it is easier to inspect a json object instead.

For /api routes, and with higher order frameworks like Nuxt, it might make sense that we use HTML in browser at least. i belive this something doable in Nuxt (since it has it's own copy version of this)