As far as the safety associated with Entity is concerned - how about
using it in the higher-level API ?
Sergey
On 31/08/11 12:19, Sergey Beryozkin wrote:
> Hi Marek
> On 31/08/11 12:08, Marek Potociar wrote:
>>
>>
>> On 08/31/2011 12:09 PM, Sergey Beryozkin wrote:
>>> I think it's good to try and model a nice and very clean process such as
>>> "Have a target URI created first", next go "Request" - set headers
>>> there, may be an entity and do a call, this is all
>>> sounds good.
>>> But I think it proves a bit too rigid/inflexible.
>>
>> That's how it is supposed to be. The fluent API should gently prod you
>> in the direction of writing a well-formed HTTP
>> requests. If you need to write something that is not well-formed, you
>> certainly can, but it may not look nice. And
>> that's actually a good thing.
>>
>> An if you really need a lot of extra flexibility, you can always use
>> the Invocation API. It may be more verbose, but
>> that's the tax for the flexibility. You should not use that API if you
>> really need only something simple anyway.
>>
> +1 to the above thoughts.
>
> IMHO the current version is inflexible. I don't understand how
> disallowing for an explicit CT setter or enforcing an entity wrapper,
> without having to resort to Invocation, and not being able to build a
> simple iteration logic, can protect a user from creating non-well formed
> requests.
>
> Are you concerned about POSTs containg no CT ?
> I can kind of get that, but this is a low-level API, obviously users
> have to get some ideas of what formats are supported by the end receiver
> ? By adding this tight entity wrapper and not letting set a CT as is is
> not cool - likewise the fact I can't get back to resetting some bits of
> the current URI once I moved to a request stage is a big limitation IMHO
>
> Thanks, Sergey
>
>> Marek
>>