You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think we might be using the UML "isID" property of an attribute in a misleading way. I have used it to indicate the attributes of the target class of an aggregation (eg vessels) that might be useful to return in the structure of the source class (eg voyages). The idea is that these data elements should be sufficient to know exactly which vessel is doing the voyage - without returning all the properties of the vessel in the query response about a voyage.
But the UML "isID" is one way to tag attributes. Another way to use a UML construct called a "tagged value". UML Tags are name/value pairs so we could have a tag name like "OpenAPI" (which means the open API generator should look for these tags) and a value like "query". That would mean that the API generator should include this property as allowed GET query string parameters.
Another OpenAPI tag value might be "aggregate" - meaning include this property in the data model of the source class when generating API. In general we can add optional richness to API generation by adding more tag values that drive specific treatment by the generator.
Thoughts?
The text was updated successfully, but these errors were encountered:
I think we might be using the UML "isID" property of an attribute in a misleading way. I have used it to indicate the attributes of the target class of an aggregation (eg vessels) that might be useful to return in the structure of the source class (eg voyages). The idea is that these data elements should be sufficient to know exactly which vessel is doing the voyage - without returning all the properties of the vessel in the query response about a voyage.
But the UML "isID" is one way to tag attributes. Another way to use a UML construct called a "tagged value". UML Tags are name/value pairs so we could have a tag name like "OpenAPI" (which means the open API generator should look for these tags) and a value like "query". That would mean that the API generator should include this property as allowed GET query string parameters.
Another OpenAPI tag value might be "aggregate" - meaning include this property in the data model of the source class when generating API. In general we can add optional richness to API generation by adding more tag values that drive specific treatment by the generator.
Thoughts?
The text was updated successfully, but these errors were encountered: