intrinsically
commented
2 years ago Not sure this is relevant to this discussion, it sounds like a weird Spring codegen thing, but i thought i'd mention it. You may be already aware, if so please ignore.
In Reslang you can change the return selectively for an operation. e.g. in the FIles.swagger example in the models directory you can see the overriding of the return for a 200 on an action. You can use this pattern everywhere you have an "error" which can also be a success code.
"This models an action on a request" sync action DirectoryDeleteRequest::Cancel { id: int time: datetime
/operations
POST 200 DirectoryDeleteRequest::Cancel}
Describe your request
Copied from Jira: https://liveramp.atlassian.net/browse/OC-21931. Had to resolve that ticket as Won't Do (team bandwidth), but opening here for tracking --
Slack convo started in https://liveramp.slack.com/archives/C2R3TK43Z/p1608083439206000
When there's Reslang changes, the generated Spring models expect different InlineResponse models to be returned (I've seen InlineResponse201, InlineResponse2011, and InlineResponse2012) instead of staying consistent
Identified symptoms and impact unrelated changes lead to InlineResponse model changes (which has IDs as either String or UUID)
How to reproduce code gen https://github.com/LiveRamp/api-specs/pull/454 and notice how the DistributionRequestApi, IntegrationConnectionApi, and RealTimeDistributionConfigApi use different InlineModels in the ResponseEntity
Describe the value this feature would provide Avoid unnecessary breaking changes to client and server stubs, which reference InlineResponse objects by an unstable number.
@nliu132 @JacobCrofts FYI