Hacker News Reader

Comment by catlifeonmars | Hacker News Reader

What if you need to generate two server implementations (possibly in different languages) that adhere to the same specification?

You don’t always go server -> spec -> client.

View on HN

That seems like a rare use case. Surely we optimise for the general use case - you start working on a new server powered platform, and write it once in your stack of choice, and release libraries for clients (mobile apps, integrations, web apps).

Even so, a e2e test suite would surely serve far more utility over a spec that simply stubs out endpoints with no functionality.

for internally consumed APIs I somewhat agree, but if you wanna expose APIs to external developers it usually does pay off to spend a bit of time on the API design itself, what APIs would you expect to see if you were the user of the your own service - and this is where tools like this really help imo - you could even preview your API in some openapi doc tool like readme or similar, in which case it's like previewing your product before releasing it

It is not at all uncommon to want a spec for an api that’s out of your control. Or to want to define shared data structures at the transport layer which may have “owners” in heterogenous languages. Spec languages are (well, can be—so very many are terrible) very nice in those cases, which are not at all rare. They may well be more common than the “we’re writing a new single-language monolith that is free to control the shape of the data it slings” use case.

Reply on news.ycombinator.com