finos
Include Data Exchange Format On Interface
Feature Request
Description of Problem:
There is no way to describe the format when exchanging data between two nodes. Example: Binary, Json, XML, Text etc.
Potential Solutions:
We are proposing adding exchange formats to interfaces to allow users to specify the format of data that is exchanged between nodes using an interface.
"data-exchange":{
"$ref": "#/defs/interface-type",
"type": "object",
"properties": {
"format": {
"type": "array",
"items": {
"$ref": "#/defs/exchange-format"
},
"uniqueItems": true
}
},
"required": [
"format"
]
},
"exchange-format": {
"enum": [
"binary",
"file-upload",
"json",
"text",
"xml",
"other"
]
}
Is there an existing standard we could model this around - or indeed should we look at integrating with an existing standard such that we don't end up needing to frequently update the exchange format enum?
Is there an existing standard we could model this around - or indeed should we look at integrating with an existing standard such that we don't end up needing to frequently update the exchange format enum?
@rocketstack-matt I wonder if we can use something like the Content-Type header approach from HTTP/REST. They have a pretty comprehensive Media Types list, e.g. this https://www.iana.org/assignments/media-types/media-types.xhtml
At that point, would this become a control-requirement rather than a change to the schema? You could specific a control requirement that Content-Type must be included and then specify the actual content not the control-config?
@rocketstack-matt I think that could make sense, especially if we adopt the central controls (for core things like this). I quite like the idea of being able to specify that if you're using OpenAPI for example, you can optionally provide an OpenAPI specification. If you're using Websockets, you can optionally specify an AsyncAPI.
Thinking about it, a lot of this would sit at the basis of an API domain, which we have discussed but not captured at this point.
Lets look at remodelling this as a control-requirement to see if it provides a more flexible alternative to maintaining a long list of exchange formats, in this model exchange format would be a control-configuration.
I think making the data-exchange type as a control in a pattern makes sense, however, when you describe an interface should you not define how you interact with it? We can pull the media-types as James has suggested. It should not grow very quickly.
Additionally I think that the case of data-exchange-type is much more suitable as an interface over some of the other interfaces we have such as: "oauth2-audience-interface" and "rate-limit-interface". Do these then get converted into a control as well?
Also agree with @Budlee here. I think there is value in it being an interface with pulling the main content types from the standard. I can see it as both an interface to denote the data type of data transmitted to/from that service and a control as it relates to compliance/policies. Data between services would likely be a finite set of types that would fall under the standard and an interface helps list that in the same way as the other core interfaces we have as part of the scheme currently.
Will be supported via standards implemented by each org using tailored to their own needs, as providing a centrally hosted solution will never be able to encompass everyone's needs.