If we ever want to be able to call our REST endpoints from within OpenContent, we will want to abstract out all of the code in the REST endpoint that we would want to use somewhere within OC. The prime example is the following:
From within OpenContent, java code needs to be able to get a config from the repository (ex: call the "/configs/{type}" endpoint). Without duplicating code, the only way we can do this currently is to wrap up and make a REST call from within OpenContent to OpenContent which is wasteful.
We should have all of the methods in an IConfigService interface, and then move all of the logic currently in RESTConfigService into a new ConfigServiceImpl class that implements IConfigService.
Shouldn't have to write any new actual code, just a refactor that would allow internal OC code to be able to use its own code. It also gives us the ability to extend/override methods much easier if we come across a need to do that for a specific repository or a specific client request.
In general, we should be avoiding doing much logic in any REST.java classes and put them in Interfaces/Implementations. Acceptable code to have in a REST.java code is processing of the wrapper objects to get them into the format/objects that we need to do the actual work.
If we ever want to be able to call our REST endpoints from within OpenContent, we will want to abstract out all of the code in the REST endpoint that we would want to use somewhere within OC. The prime example is the following:
From within OpenContent, java code needs to be able to get a config from the repository (ex: call the "/configs/{type}" endpoint). Without duplicating code, the only way we can do this currently is to wrap up and make a REST call from within OpenContent to OpenContent which is wasteful.
We should have all of the methods in an IConfigService interface, and then move all of the logic currently in RESTConfigService into a new ConfigServiceImpl class that implements IConfigService.
Shouldn't have to write any new actual code, just a refactor that would allow internal OC code to be able to use its own code. It also gives us the ability to extend/override methods much easier if we come across a need to do that for a specific repository or a specific client request.
In general, we should be avoiding doing much logic in any REST.java classes and put them in Interfaces/Implementations. Acceptable code to have in a REST.java code is processing of the wrapper objects to get them into the format/objects that we need to do the actual work.