There is a javax.ws.rs.core.Form proposed to be introduced as part of JAX-RS 2.0 API as a general-purpose support for
form-encoded data. It's been there since HttpRequest/Response were introduced early in June. I just stripped it off the
annotation-support methods so right now it's (again) merely a typed extension of MultivaluedHashMap<String, String>
without any added value. It's perhaps questionable if we need the class, but I'd prefer we brainstorm for potential
value-add methods the class could host before we decide to drop it. We can drop it, if we can't find a good reason for
keeping the class in the API.
In any case, whether we decide to keep the Form or if we opt for going with a generic MultvaluedMap<String, String> as a
representation of form-encoded parameters, I can see few options we should consider:
1. Provide a static Entity method:
Entity.form(Form formData) or Entity.form(MultivaluedMap<String, String> formData)
2. Introduce public Entity Form.asEntity(); method. This one would require we move Entity into core package to avoid the
dependency from core to client.
3. Provide another post() overload:
SyncInvoker.post(Form formData); ...I wouldn't agree with the generic Map-based version in this case
The order above also shows my preference. Option #1 seems to be most consistent extension to the current API. Option #2
is almost as good, but it still feels like we would be moving some client-side concern to the core Form API. Option #3
would be our acknowledgement that post(Form) is by far most expected use case scenario, but it's not consistent with the
current approach of encapsulating entity-specific topic in the Entity class.
Let me know if any of the above looks good or if you see another option(s).
Marek
On 08/29/2011 04:53 PM, Bill Burke wrote:
> No matter whose proposal you look at, everybody pretty much ignores form parameters. IMO, form parameters will be
> typical usecase with POST invocations.
>
> Something like this would be really ugly:
>
> target.request().post(Form.param("foo", "bar").param("bar", "foo));
>
> It starts to look like LISP. What sucks is, I just know I've encouraged you to add *at least* one more interface to
> this ridiculous hierarchy.