On Feb 15, 2008, at 11:57 AM, Martin Grotzke wrote:
>
> thanx a lot for your response!
>
> IMHO the status code is more related to the response itself than a
> representation of a resource. This makes sense to me, as sometimes I
> simply do not have (necessarily) any representation within the entity
> body of the response. So, creating a respresentation element simply
> for
> beeing able to specify the status code seems - at least to me - to be
> some kind of workaround, but not well designed.
>
> Though, it makes sense to refer to a certain scenario / status code
> from
> a representation, as the representations may be different for
> different
> results / status codes. But I would think more in terms of
> "refering" a
> status code...
>
> Just thinking about that - no complaints :)
>
I suppose allowing multiple sibling Response elements and having the
status on those might be more amenable to what you are trying to do.
Marc.
>
>
>
> On Fri, 2008-02-15 at 09:43 -0500, Marc Hadley wrote:
>> On Feb 15, 2008, at 8:34 AM, Martin Grotzke wrote:
>>>
>>> I have a POST operation that returns HTTP 201 with an appropriate
>>> Loction header and the representation that would be returned when
>>> the
>>> value of the Location header would be requested via GET.
>>>
>>> Is there another way of specifying the HTTP status for a response,
>>> than
>>> setting the status attribute of the representation?
>>
>> No, that's how you do it.
>>
>>>
>>> What would I do, if I would not return anything (but 201 and the
>>> Location)? How would it be possible to specify that 201 is returned?
>>>
>> The only way I can see is to have a representation with only the
>> status attribute set. Note that you can also include a param with
>> style="header" in the response to be explicit about the location
>> header.
>>
>> Marc.
>>
>> ---
>> Marc Hadley <marc.hadley at sun.com>
>> CTO Office, Sun Microsystems.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_wadl.dev.java.net
>> For additional commands, e-mail: users-help_at_wadl.dev.java.net
>>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.