On Dec 15, 2008, at 10:23 PM, Ferdy Nagy wrote:
> Thanks Paul, specifically I'm doing this to support ActionScript/
> Flash applications that have a restriction where they cannot set the
> headers for anything other that POST, so they need to use the
> override header to make it a GET, but, if the URL contains any query
> parameters it automatically reverts back to GET and drops any custom
> headers - you really have to admire the genius behind some of the
> actionscript libraries.
!!
> Another reason I want to support sending parameters in the body via
> POSTing a GET is that the query parameters may be long and the url
> may become unwieldy or max out (GData also supports parameters in
> the body).
>
OK.
> My resource is still fundamentally a GET, which also takes POST
> (create), and PUT (update) so using POST with an @FormParam would
> break the REST paradigm.
I understand now. You are working around restrictions in the
ActionScript/Flash client but want to retain a clean server-side API
and use a filter to hide the work arounds.
> I don't think it's unreasonable to expect that using the X-HTTP-
> Method-Override to coerce into GET that the parameters should be
> available as though it was an actual GET request - but I do agree
> that the parameters are in the body which goes against the grain of
> GET being uri based; then again, so does the override header.
I misunderstood your intent. But what you describe above makes sense
now: converting the POST with form parameters to a GET with query
parameters.
>
>
> >> I'm using a PostReplaceFilter so that a caller can GET a resource
> >> via a POST operation, which works fine; however parameters sent in
> >> the body with content-type: application/x-www-form-encoded are not
>
>
> >> available, they're always empty in the parameter map. It works if
> >> the parameters are included in the query string.
> >>
> >
> >When you say "parameter map" what are you referring to? Can you share
>
>
> >some code?
> @GET
> public Response get(@PathParam("entityId") Integer eid, @Context
> HttpServletRequest req) {
>
> // Some of the parameters follow a pattern, like param.1.XX or
> param.2.XX so I need to
> // have access to the parameter map directy
>
> // This will always be an empty enumeration when using the replace
> filter with the parameters
> // in the body
> Enumeration<String> names = req.getParameterNames();
>
> // Using the UriInfo getQueryParameters is also empty - presumably
> for the same reason the
> // ServletRequest parameters are also null
> }
>
>
> >It seems as if you want to do something very specific and convert
> form
>
>
> >parameters of a POSTed request entity into query parameters of the
> >request URI, is that correct?
>
> I added this to the PostReplaceFilter and it works like a charm; I
> think this is something that most people would want if they are
> employing the method override...
>
> // If we got some parameters encoded in the body for this
> override GET request
> // pull them out and add them to the query.
> String contentType =
> request.getRequestHeaders().getFirst("Content-Type");
> if ("GET".equalsIgnoreCase(override) &&
> MediaType.APPLICATION_FORM_URLENCODED.equals(contentType)) {
>
> Form form = request.getFormParameters();
>
> if (form.size() > 0) {
> UriBuilder builder = request.getRequestUriBuilder();
> Set<Map.Entry<String, List<String>>> entries =
> form.entrySet();
>
> for (Map.Entry<String, List<String>> entry:entries) {
> builder.queryParam(entry.getKey(),
> entry.getValue().toArray());
> }
>
> request.setUris(request.getBaseUri(),
> builder.build());
> }
> }
>
Great! this is a nice filter (it is not clear from the code but you
might also want to check that the request method is also a POST, just
in case...). We should add it to the source base. If willing would you
like to log an feature issue and attach some source?
>
> Jersey is a really nice implementation, the ability to easily
> leaverage the IoC and create custom injected properties along with
> the provider mechanism is great; well done!
>
Thanks!
Paul.