Good stuff!
With regard to the advanced dispatcher stuff, indeed that is what is
throwing you off. I’ve worked around this (also in a spring webmvc project)
by doing the following in a servlet filter.
root="/api"
if (servletPath != null && servletPath.startsWith(root)) {
//hack to deal with the GeoServer "advanced dispatch", the point here
is that
// we want to expose our api directly at "/api"
req = new HttpServletRequestWrapper(r) {
@Override
public String getRequestURI() {
return super.getRequestURI().replace(root, root + root);
}
};
}
There may be a better/cleaner way to do this, but this worked.
Also, if I can offer a suggestion about the endpoint name, using something
like “/api” might be a bit more aesthetically pleasing than “/restng”… and
more inline with how I’ve seen other modern servers expose restful apis,
fwiw.
-Justin
On Wed, Mar 15, 2017 at 10:42 AM Devon Tucker <dtuc...@boundlessgeo.com>
wrote:
> Hi all!
>
> Even though I'm not coming to the REST refresh sprint I've been doing some
> preparatory/research for it. I'm wondering if anyone on the list has
> started looking at it yet or worked out an example? I took a stab
> yesterday, it definitely raised some questions.
>
> Here's what I did:
>
> - Created a new top level module, rest-ng, that uses Spring MVC
> - Created a StyleController in order to recreate our styles REST endpoint.
> - Mapped this endpoint to "/restng/styles"
> - Returned a list of StyleInfo objects
> - Attempted to configure a new HttpMessageConverter to potentially handle
> the FreeMarker HTML responses
>
> That's about it. Just this raised a decent few questions and problems for
> me:
>
> - Right off the bat despite mapping my new endpoint to "/restng/styles" I
> found that it actually ended up being mapped to "/rest/restng/styles". I
> can't for the life of me figure out why that's happening. I tried removing
> the existing rest and restconfig modules from the project, removed the REST
> wrapper config and still had this issue. Maybe not a big issue in practice,
> since we want all the end points to be under /rest presumably, but it'd
> certainly be nice to know WHY this happens. Something to do with the
> AdvancedDispatchFilter maybe? (In fact after a little digging this seems to
> be the "culprit")
>
> - Conflicting Spring MVC contexts. I used the <mvc:annotation-driven/>
> directive to enable Spring MVC in my module. Then I added a new
> HttpMessageConverter (like this https://dzone.com/articles/customizing)
> to customize response handling. I could see the new converter being
> instantiated and added to the list of converters, however during the
> response cycle it was nowhere to be found. It seemed like internally there
> was another Spring context that was being used that had the default
> converters. If I remove the <mvc:annotation-driven> directive from my
> context then my new converter DOES get used though. This is interesting
> though because the only references to Spring MVC are in community.
>
> - How should HTML responses be handled? Spring MVC RestControllers aren't
> really meant to return HTML. AFAICT the options are use the actual
> ModelAndView functionality with freemarker views, which would involve
> separate controller methods for HTML calls, or to create a new
> HttpMessageConverter to handle HTML requests. Both probably have issues.
> Creating a new MessageConverter is a little problematic, since these are
> centralized and orthogonal to the actual controllers. HTML responses in the
> current REST framework rely a lot on the type hierarchy of the RESTlet
> controller that handles the request. It's a little tougher to do it this
> way in Spring MVC because the response encoding happens outside the
> controller lifecycle.
>
> - This seems a little more straightforward, but I assume we want to re-use
> all the existing XML/JSON serialization. This will require custom
> MessageConverters for those.
>
> I think that's it for now. Sorry for the wall of text.
>
> Cheers,
> Devon
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
