Implement OpenAPI Spec in existing APIs

[shrugs]

implement the OpenAPI spec for the existing APIs:

• not subgraph graphql
• Resolution API
• Config API
• Indexing Status API

[lightwalker-eth]

@shrugs A few status points on this:

• Indexing Status API: A bunch of updates will come on this API soon.
• Config API: There's a number of updates I'd like to see made here as well.

So a heads up with caution on not investing too much effort in these OpenAPI specs for these APIs until some priority refactoring on them drops. Or at least to expect meaningful changes soon.

[stevedylandev]

Hono has a great third party middleware we can use: https://hono.dev/examples/hono-openapi

We already use Zod for validation which is fantastic, makes implementation really easy. The only thing we need to add in addition is Zod schemas for responses as well vs just Typescript types, e.g.

// apps/ensapi/src/lib/handlers/response.schema.ts
import { z } from "zod/v4";

export const ResolveRecordsResponseSchema = z.object({
  records: z.object({
    name: z.string().optional(),
    addresses: z.record(z.string()).optional(),
    texts: z.record(z.string()).optional(),
  }),
  accelerationRequested: z.boolean(),
  accelerationAttempted: z.boolean(),
  trace: z.any().optional(),
});

I think I remember @lightwalker-eth mentioning he wanted something like this so we can have more robust type inference in our SDK & React Hooks.

Thankfully our endpoints are minimal now so it's the perfect time to implement something like this and use it moving forward for documentation

edit: I found a cleaner way to do this by creating response zod schemas in ensnode-sdk as seen in #1338