Is your feature request related to a problem?

Extension developers need a stable API (interface) to implement extensions.

SDK developers need a way to add additional functionality without forcing extension developers to change their code.

What solution would you like?

I propose to create a 3-layer inheritance for Extension and ExtensionRestHandler implementations.

• The Extension interface will include all the methods required by ExtensionsRunner including
  • settings
  • rest handlers
  • settings (to be added)
  • components (to be added)
• A new BaseExtension abstract class will provide default methods so users don't need to implement everything in the interface but have the ability to override
  • can provide an empty settings list so extension authors with no custom settings don't need to do anything
  • can be used for default components but allow for the extension implementation to override
  • can move the read settings from yaml convenience code out of interface and simplify the awkward user implementation with all the exception handling
• Similar layering can be done for the ExtensionRestHandler with a BaseExtensionRestHandler
  • This will create a place for an abstract class to provide optional syntax for handling REST requests as envisioned by [FEATURE] Provide a higher level implementation for REST handlers  #128

Also we should create a new ExtensionRestRequest class to be the sole argument to ExtensionRestHandler.handleRequest().

• This will keep the API stable as we add new functionality such as params ([FEATURE] Pass REST params to extensions #111) and security principal information
• Goal should be to at least match RestRequest method names exactly to ease porting extension code

What alternatives have you considered?

An interface-only model requires using default methods and exposes a lot of implementation details that aren't really needed.

An abstract-class-only model would work but from an "API" or "SDK" perspective I prefer the cleanliness of an interface.

Do you have any additional context?

@owaiskazi19 please provide some input on what the API method for creating components should look like (what arguments, etc.)
@cwperks this relates to this comment on your draft PR.
@mloufra the create components piece may touch your code after refactoring ExtensionsRunner in #116 so will try to coordinate my implementation with yours in #116. If you can let me know which branch on your local fork you're pushing code to it will be helpful.