IPIP-513: Delegated Routing V1 returns 200 for empty results

[lidel]

Changes HTTP Delegated Routing V1 API to improve empty result handling:

• servers SHOULD return 200 instead of 404 for empty results
• clients MUST handle both 200 and 404 for backward compatibility
• improves semantic correctness (404 means "endpoint not found", not "no data")
• prevents browser console errors that confuse users

Follows robustness principle for maximum interoperability (strict server, liberal and robust client).

• Related to ipfs/boxo#1024 (cc @achingbrain)

Implementations:

• Boxo (GO): https://github.com/ipfs/boxo/pull/1032
• Helia (JS): https://github.com/ipfs/helia-delegated-routing-v1-http-api/pull/174

[github-actions[bot]]

🚀 Build Preview on IPFS ready

• 🔎 Commit: 1d072cc831b72b17a2c81757ff550979c05bf631
• 🔏 CID bafybeihcvq2jpjvh5ivvf7rze4dj6vm4petl76aoffv7eehqjdqla4umyq
• 📦 Preview:
  • dweb.link
  • w3s.link
  • inbrowser.link

[aschmahmann]

This makes sense to me. I'll just flag briefly my (perhaps incorrect) historical recollection that in Reframe these responses were 200s, and the switch to 404s with routing-v1 was partially motivated by people being annoyed they couldn't just look at error codes in grafana to see the percentage of requests that had no providers.

Seems like doing the thing that follows HTTP semantics is the thing to do though so 👍

[lidel]

@aschmahmann indeed, 404 are a lazy way of tracking "no results" that abuses HTTP semantics and creates more problems for down the stack.

These days we have way better way of tracking success rate. We have histograms of response latency and results list length, but if that is too complex, I also added simpler counter of total/success in https://github.com/ipfs/boxo/pull/1032.

It shows you don't need 404 for visibility into this.