Extensions to OpenSearch communication

[peternied]

Through use of the transport service OpenSearch and the extension share java objects. This is the established mechanism for communication between nodes is an OpenSearch cluster. This design has trade-offs that we might want to consider switching to a REST based model.

Advantages for REST model:

• Implementing REST APIs is a common practice is all modern languages, there are a wealth of tools and libraries available.
• REST API requests can use common http conventions in headers for communicating meta information (Such as status codes, auth, proxy).
• OpenSearch already can expose REST APIs that are used by existing plugins.

Areas to consider before switching:

• Performance impact to using a different protocol
• Functionality within the transport service that would not translate to REST responses

[dbwiddis]

You barely mention "auth" in advantage bullet 2, but the fact that REST and OAuth2 work together seamlessly is a huge advantage.

Disadvantage is we have to implement our own security on top of REST but that is a well-understood problem.

If we select this route (I vote yes) we should immediately establish documentation of the REST API and coding standards for updating it with any API functionality change (which will be frequent as new features are added). We should look into options for doing that automatically, e.g., Swagger.

[peternied]

@dbwiddis did you have a function/code path in mind that we could start with?

[dblock]

Keep in mind that transports should be switchable. An extension that needs to exchange a lot of data may want to do something highly optimized. No strong feelings on what the default should be, or whether v1 should have more than one transport implemented.