> It does, but the generated code can be very shitty for some combinations of spec and output language. This is where a message centric approach can have advan

> It does, but the generated code can be very shitty for some combinations of spec and output language. This is where a message centric approach can have advantages. Just generate the objects for the Request and Response DTOs (Data Transfer Objects), and let the developer interact with the API via whatever HTTP/GRPC/MQ client that is appropriate. You can externally provide a client that will use those DTOs directly for a good experience for those that prefer that, but in the end the DTOs are just the messages deserialized into the target language, which is useful in most languages/clients. Having a complex tool to generate these clients from a complex spec is going to be fraught with issues IMO. An alternate approach is get the web service API framework to generate just the message contracts in many languages directly. This enables very simple tools to pull down the generated code from a live/running API. We take this approach with the ServiceStack framework [0], and have found it provides a good developer experience. Also supports OpenAPI spec generation. Each to their own, but I like this approach better than what feels like WSDL client generation all over again. [0] https://servicestack.net/service-reference https://servicestack.net/service-reference