> People sticking with REST+Json usually don't want to have > a compilation step for the API exchanges layer. Hmm. I'm not sure what you are saying. The way

> People sticking with REST+Json usually don't want to have > a compilation step for the API exchanges layer. Hmm. I'm not sure what you are saying. The way people tend to try to consume REST APIs is by generating client (and/or server code) from a spec. For instance OpenAPI 2.0. At least on Go the tooling for that leaves something to be desired, and the generated code isn't exactly beautiful. So you either depend on a library that someone generates from the spec, and then shares, or you generate it yourself. (We do this for a bunch of languages for our APIs, and the clients are ... not uniformly beautiful :-)) If we're talking about writing the REST client by hand...well...I'm not sure why one would want to do that. (Nor am I sure that's what you meant, so I'm not accusing you of that). My current workflow (in Go) for consuming gRPC interfaces is to use the buf.build package proxy. Which means I just add an import, run go mod tidy, and I'm good. I don't even need the tooling installed. As I think it should be. I suppose this could be done for OpenAPI 2.0 too. You stuff OpenAPI 2.0 specs in and you get code for a bunch of languages out. (Someone must surely have built this already?)