Type-safe REST client for Hono (without RPC notation)

[Andyyyy64]

Hi Hono community 👋

I’ve been experimenting with Hono’s type system and ended up building a small library called hono-typed-rest.

The goal is simple:
get tRPC-level type safety and editor completion, but keep plain REST-style calls like:

api.get("/customer/list")
api.post("/case/", payload)

instead of RPC-style notation such as:

client.api.customer.$get()

What it does

• Uses Hono’s AppType as a type contract (no code generation)
• Provides path completion and automatic input/output type inference
• Runtime is just a thin fetch wrapper — all the magic is at the type level

What it does NOT do

• This is not an RPC client and not a replacement for hc
• Frontend must be able to import AppType (monorepo or shared contract package)
• Currently optimized for JSON + 2xx success responses

Status

🚧 Work in progress
The API is still evolving and type-level performance can be heavy in large projects.

GitHub:
https://github.com/Andyyyy64/hono-typed-rest

I’d love to hear if others have tried something similar or have opinions on REST vs RPC-style clients in Hono!

[yusukebe]

Very interesting.

[Andyyyy64]

Thanks! 🙏
I built this mainly because I like Hono’s type system but personally prefer REST-style calls over RPC notation.

I’d love to hear your thoughts if you see any pitfalls or better ways to extract schema safely from AppType.

[Andyyyy64]

I've just updated the library to be much more production-ready! 🚀

Key improvements:

• Improved schema extraction to support OpenAPIHono and custom Env types out of the box (making integration much easier).
• Hardened success response inference to correctly handle multi-status unions, preventing success types from collapsing into {} when error schemas (like 401/404) are present.
• Added robust error handling and explicit 204 No Content support.

It feels much more solid now for real-world usage!

[yusukebe]

Tweeted: https://x.com/yusukebe/status/2008713437199917479?s=20

[Andyyyy64]

posted https://zenn.dev/andyyyy64/articles/d8ffe5f26d4a56