-
Notifications
You must be signed in to change notification settings - Fork 35
UI Tables and APIs
This is proposal document with intent to remove jmesa library used for server side table generation and replace it with something that is more maintainable. Currently jmesa is one of the stopper that prevent the switch to from javax to jakarta namespace with newer java versions. The replacement will likely need to use new REST endpoints to fetch data or views from server to present to the client. It should be UI only specific API, not intended for third party system integration
These REST APIs are legacy and we should not be extending them. They are present to keep the backward compatibility with OpenClinica. Thew APIs are enabled via definition of servlet and servlet-mapping in web/src/main/webapp/WEB-INF/web.xml. The authentication patterns for spring security rules are defined in web/srv/main/resources/org/akaza/openclinica/applicationContext-security.xml, however the actually authentication and authorization rules are implemented within web services code itself.
Note: OAuth endpoints, there may be still some fragments left but most of it was removed already from source code. Those have been used only for the purpose of RuleDesigner which we no longer support in LibreClinica. I am not listing those here. Also SOAP services are different story/ module.
Only relevant for ePRO extension dealing with OpenRosa and Enketo.
- url-pattern:
/rest2/*- pform - user session
uses jersey spring servlet. Code is present in web/src/main/java/org/akaza/openclinica/web/pform. Here the idea was to control authentication via third party component (proprietary).
Relevant for restful URLs, that is functionality supposed to be invoked while user logged in the application (not specifically designed for third party application integration). In a way something similar I would suggest for our new tables endpoints.
- url-pattern:
/rest/*- restful URLs - user session
uses jersey spring servlet. Code is present in web/src/main/java/org/akaza/openclinica/web/restful. Uses RestODMFilter in web/src/main/java/org/akaza/openclinica/web/filter/rest to enforce authentication and authorization rules.
- url-pattern:
/pages/*- user session
uses spring DispatcherServlet. This handle also requests origination from GUI. Not strictly web services only. It is the newest addition, where newer GUI views are using these controllers. And some of user session bound web services are also defined as controllers.
Endpoints that allow apiKey based authentication, for third party application integration.
- url-pattern:
/pages/auth/api/*- ApiSecurityFilter - ApiKey
core/src/main/java/org/akaza/openclinica/web/filter/ApiSecurityFilter. Configured in core/src/main/resources/org/akaza/openclinica/applicationContext-core-security.xml.
Similar as the one above but does not require active GUI user session.
proposal (e.g. datatables specific APIs or htmx specific APIs). I would recommend to continue with SpringController approach, without apiKey auhtentication and without versioning as those should be internal services not used for third party integration.
- endpoint for each view that needs tabular data e.g.
/pages/lc/ui/datatables/managestudy/studies
- endpoint for htmx (in this case I guess that there would be many endpoints needed for each jsp view where mesa table is present).
/pages/lc/ui/htmlx/*