On Dec 10, 2008, at 7:51 PM, Markus KARG wrote:
>
> Paul,
>
> I do not see that 400 would be a correct return code, since 400
> means "The request could not be understood by the server DUE TO
> MALFORMED SYNTAX.". The syntax was not malformed, it was pretty
> correct!
It depends on what you want to do. The syntax of the request may well
be malformed because a request entity is absent but a request entity
is required. The malformed syntax applies to the whole request and not
just to the syntax of request entity.
As you point out it is correct for a WebDAV method (i presume it is
allowed in the specification?) but for another application a HTTP
method may require a request entity and in this case having the
application have to check for null would be annoying when the
framework could do that.
> So still I believe that nobody out there would say something against
> a single solution of injecting null.
You mean a default solution or an optional solution?
> Maybe we should let people vote? ;-)
>
:-) i think it requires more discussion/exploration of the best way to
provide such a solution.
Part of the difficultly i am having with arriving at a solution is a
method such as:
@POST
@Consumes("application/xml")
public void post(String xxx) {
}
states that it consumes something. Now if i have two method consuming
something:
@POST
@Consumes("application/xml")
public void post(String xxx) {
}
@POST
@Consumes("application/json")
public void post(String xxx) {
}
then if the Content-Type is absent then which method would get called?
we need a way to state that one of these method may be called if the
Content-Type is absent or another method that gets called when the
Content-Type is absent, for example:
@POST
@ConsumesNothing
public void post() {
}
And we need to define the case of what happens when the Content-Type
is present but the content length is 0.
In the WebDAV case is the Content-Type absent from the request?
Paul.
> Regards
> Markus
>
>
>
> For the issue with the empty bodies: We need to find a solution
> since it's really a black spot on the overall great API. I think it
> would be not much a problem to convince everybody that it makes more
> sense to inject null instead of throwing a NullPointerException? :-)
>
> Yes, i can see it both ways. Sometimes you want a null value to be
> propagated and sometimes you do not and want a 400 response instead
> (the latter probably being the most common i suspect).
>
> One solution is to have a separate resource method for a request
> that does not contain a request entity. Another could be to
> annotation the request entity or the resource method that declares
> if there is not content-type then the entity should be assigned a
> null value. I think i prefer the latter solution.
>
> Paul.
>