I finally gave up as well and converted our development over to the OpenApi-YAML-first method of development, and it works well now for us. I like the fact that we have a dynamically-maintained "live" spec file that we can tap into from a Swagger UI that lets developers see and test our API. Now that I'm on the other side, I can see this is a much better method than the way I was doing it. That's not to say it will work for everyone but I'd recommend everyone at least give it a try - it might work better than you think. At least it did for me.

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?"

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.