Which protocols and patterns should we be defining?

[kinlane]

Which protocols and patterns should this group work to define? HTTP / REST is assumed at this point, but what other protocols or patterns should we be considering (ie. gRPC, GraphQL, Websockets)?

[swaldron58]

With the goal of lowering the cost to publish and consume travel products and services via APIs, we need to address API chaos. An example is maintaining connections with the 400 largest airlines in the world costs millions per annum. The major distribution companies of air tickets employ IT staffs numbering in the thousands of which 75 to 80% of what they do is maintaining existing connections. Message standards while widely adopted fall short of the need. The messages exchanged via APIs look similar but don't act similar. Overloading of message elements is common. Messages can provide data like a price but don't convey the rules of use. There are no conventions on how to exchange rules. Most happen today via a sideband such as another data feed or text in a commercial agreement. Process flows are just as mysterious.
Proposal:

• Define how to support a common resource of data definitions. Open Travel is providing today a common domain level library as an example.
• Define non functional API behaviors such as a means to dynamically access rules and next best actions (process flows).
• Define how the use of common data definitions and API behaviors can be measured for certification purposes.
• Define how local extensions of any of the above may be accommodated. This includes backward compatibility needs for continuing use of legacy back ends.
• Define best practices for API publishing and operation.

Note: Outside of this workgroup(s) there may be other efforts such as how to support wizard like functions for travel providers to easily describe and publish their travel products and services using the above efforts. Another means to take costs out by making publishing of travel cheaper.

[swaldron58]

We need to discuss establishing patterns that adhere to REST versus those that use GETs, PUTs and POSTs but the URL is not a resource but a function. I've called this various things, my current favorite being JSON-RPC. We do need the latter as there are a lot of legacy systems out there we can not ignore.
My soap box on this (SOAP pun intended), is that titles and definitions of accepted patterns is important. We can't let teams call outcomes REST (and/or microservices) when they are not. If someone tells me I can connect via REST I immediately have many expectations on the message exchange pattern and the overall behavior of the API. I will have expectations on compatibility with my functions which means expectations of cost. This is not rooted in technical correctness but capability and cost.
In the Open Travel model, we have done some work but need to do more of the differentiation of message exchange patterns and the impact on the model. In turn, how we use names spaces and other techniques to prevent whatever we need to provide for backward compatibility from impacting future flexibility for those implementing REST.
Part of the patterns we establish needs to accommodate both process and data security. Most existing patterns based on RPC (SOAP, etc.) assume parameter based security (firewalls). We need to focus on data and function level security at the API level and assume network functions are virtual (trust no one). Assume all resources are virtual and not dependent on firewalls of the system. This will impact our thinking on message exchange patterns.

[kinlane]

A lot of what you are describing is encoded in a complete OpenAPI definition, and can be validated using JSON Schema and a linter. The SOAP to REST conversation should be addressed as separate sub-group, but critical.

[kinlane]

Sounds like a full focus on REST / HTTP is where we start. Flesh out the models, and OpenAPIs for access, then we can move to other areas.