i could not give statiscally meaningful numbers in that regard. We had customers asking about that, and it is a fairly cheap
to implement solution, so it was a no brainer to add it. Hence I have only annecdotes to pass as evidence :)
In the end of the day though, if you have a company behind a firewall with this problem, it helps the adopters there to a significant
degree (like: "we can use it" compared to "we need to drop this"), so i would venture to say that it's well worth the few additonal lines of code...
Regards
Frank
On 6/25/06, James M Snell <[EMAIL PROTECTED]> wrote:
Ah yes, I'd been meaning to ask y'all about this. Have you found very
many environments in which the PUT/DELETE support is a problem? We're
looking at a similar problem and had been kicking around a header-based
solution also.
- James
Frank Mantek wrote:
> If we send POST OR PUT depends on a FLAG that you can set in the client
> libraries. this flag, called MethodOveride, if set, converts PUT and
> DELETE HTTP calls to POST calls with an additional header
> (X-Method-Override) to indicate if this orignally was a PUT or DELETE.
>
> This is there for certain network configurations (firewalls etc) that do
> not allow you, the user of the client libaries, to use PUT & DELETE.
>
> Frank Mantek
>
> On 6/24/06, *[EMAIL PROTECTED] <mailto: [EMAIL PROTECTED]>*
> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
>
>
> Hi Guys,
>
> I was debugging my own Atom server implementation and noticed that you
> are sending POST for updated instead of PUT. Any reason why you are
> deviating from the specification? REST? etc.
>
> -Elias
>
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Google Calendar Data API" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/google-calendar-help-dataapi
-~----------~----~----~----~------~----~------~--~---
- Re: Using POST instead of PUT Frank Mantek
- Re: Using POST instead of PUT Elias Torres
- Re: Using POST instead of PUT Kyle Marvin
