Thanks for the reply, but I'm not seeing that this answers your original, and my duplicate, question about how to provide certain OpenAPI attributes when coding IRIS REST services using the manual approach. I wish I could use the spec-first approach but I don't see how that would work in my organization. We have a need to do things in such a way that the manual approach is going to be the only feasible way to make it work, without getting too down in the weeds with an explanation. So I'm just looking for a way to modify my exiting REST classes, that extend %CSP.REST, or perhaps add a class to my service class suite (that includes the Dispatch class, so that it provides the necessary OpenAPI spec attributes.
I have the exact same question! Can someone please provide a response to this? For what we are trying to implement, spec-first is not really sustainable, but I do want to be able to have the Swagger API documentation being updated on-the-fly via this process. But as the OC pointed out, these attributes are missing in the code-first approach and we'd like to know how to add them, if at all possible (and I really hope it is!).
Yes, we have a significant REST hand-coded API already in place and in use. I was hoping there were attributes I could add to my existing classes that would "fill in" the missing OpenAPI attributes when calling GET /api/mgmnt/v1/:namespace/spec/:application/ to pull the OpenAPI spec for a Swagger UI. So, bottom line is, there is no solution? Or the solution is "don't hand-code services, use isc-rest?"