Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid unnecessary changes to InlineResponse models #176

Open
cjea opened this issue Jan 9, 2021 · 1 comment
Open

Avoid unnecessary changes to InlineResponse models #176

cjea opened this issue Jan 9, 2021 · 1 comment

Comments

@cjea
Copy link
Contributor

cjea commented Jan 9, 2021

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

@intrinsically
Copy link

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

}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants