Develop a strategy to refactor REST endpoint code used by Galaxy/BAR/CyVerse (maybe AppStore)

Also should look at:

• appstore module
• Plugin Manager module, service package
  The above implements a REST endpoint for managing IGB Apps.

Note:
The NanoHTTPD server code is now being provided in shared-lib-wrapper.
Scope in POM.xml files should be changed to "provided" as of now.

We can also look for the alternatives of nanoHTTPD which are JAX RS and Jetty.
It will be beneficial if we look for an alternative to nanoHTTPD because in future if the number of endpoints increase then it would be difficult to handle such situation with the existing functionality.

Helpful tutorial link for JAX RS:
https://javabrains.io/courses/javaee_jaxrs/

Jetty vs NanoHTTPD
https://java.libhunt.com/compare-nanohttpd-vs-jetty-project

To-do:

• Check whether felix includes jetty bundle; can we use it?

Some ideas that might be a good direction to go:

• IGB should listen to a single port on localhost
• All endpoints should look like: localhost:PORT/igb
• Whatever is "listening" to this port should examine the request and forward to REST endpoint handlers

For example, we should maybe have a single endpoint handler that grabs the parameters or paths following localhost:PORT/igb and figures out what to do. Possibly anything that wants to support a REST endpoint would register itself with this handler - maybe by providing an OSGi service.

For example service architecture, look at how Apps can add menu items to IGB "on the file"

Look at:

• https://bitbucket.org/lorainelab/super-simple-igb-app/src/master/

Refactoring Strategy:

All requests will have a this format: localhost:PORT/igb/SOURCE/ACTION. Source will be one of these (Galaxy, Bar, IGBApp, CyVerse, Bookmark, etc). Actions would be get/post requests coming from those sources. The parameters would be added in the body of the request.
There would be a parent RequestHandler, different Sources will extend the Common request handler to handle their respective requests. This would make the code modular. Generic methods and implementations will go in the parent handler. This will achieve separation of concerns.

Dr. Loraine, is this approach in the right direction?

I think we should implement this using declarative services, similar to how IGB allows Apps to add new menu items to "Tools" and other top-level menus.

This feature is implemented via a "menu api".

See: https://bitbucket.org/lorainelab/super-simple-igb-app for a simple example.

SuperSimpleIgbApp implements MenuBarEntryProvider, an interface in API package org.lorainelab.igb.menu.api. SuperSimpleIgbApp is declared as a "Component" configured to start as soon as it is installed - using the "@Component immediate=true" annotation.

Meanwhile, corresponding @Reference annotations in MenuBarManager (in com.affymetrix.igb.util) annotate methods that accept MenuBarEntryProvider objects, such as SuperSimpleIgbApp.

When a user installs an IGB App that implements MenuBarEntryProvider and contains an @Component annotation, any @Reference methods belonging to other @Component methods which accept MenuBarEntryProvider objects get invoked. These "@Reference" annotations "inject" MenuBarEntryProvider objects into corresponding @Component objects.

The "manager" merely adds or removes the menu items from the GUI. It does not dictate what the menu items actually do. Other code does that.

I am thinking we need something similar - a "REST request" manager that will forward requests to all endpoints that have been added.

Looking into possibly using RouterNanoHTTP

CyVerse needs an endpoint!

This task is very open-ended. I think we have done sufficient documentation for first stages of this. Closing.