Rest support of CAS is currently provided via the restlet library. The integration need to be converted to be based on Spring MVC support for REST calls. This would remove the dependency on restlet which causes a number of issues in the past by pulling conflicting another JARs into the build.
As far as the documentation - there is not much to it - just include the module dep. in in the pom and for existing restlet users change the restlet servlet mapping of /v1* to the cas dispatcher servlet mapping (or just delete the overlay web.xml all together). Those notes are included in PR.
Best, D.
ScottSJuly 8, 2014 at 11:54 AM
I concur with both of you
1. New module makes sense 2. Deprecating class/old module makes sense 3. I think our "public API" in this instance is actually the URL pattern and not the specific classes.
Its also good to see that years later Dimo is still on his Groovy kick p.s. does the pull request include updated documentation?
In terms of public API - the only thing considered a public API is the resource URI I.e. /v1/tickets. The classes implementing it are internal implementation details. In Restlet impl they are split between 2 classes TicketResource and TicketGrantingTicket resource. I don't see any reason to do the same in the modern @RestControler implementation. It will be one TicketsResource class with all 3 resource URIs methods. Totally reasonable, modern way of implementing restfull resources.
Rest support of CAS is currently provided via the restlet library. The integration need to be converted to be based on Spring MVC support for REST calls. This would remove the dependency on restlet which causes a number of issues in the past by pulling conflicting another JARs into the build.