That's a valid point.  What do you think of following on GETs and
throwing an exception for POSTs?  Not sure many people like to deal
with exceptions (I prefer them).

Do you know the behavior of the 302 for a POST?  Does the write get
queued for later?

The only issue is that if the library has to inspect the headers, then
it adds some "serialness" which could actually decrease performance.
For example,

// make api call
// query database and other stuff
// block for api results
// follow 302 by making another call

is at times going to be slower than

// make a blocking api call which follows a 302
// query database and other stuff

On Sep 1, 3:03 pm, davidddn <> wrote:
> On Sep 1, 5:00 pm, jmathai <> wrote:
> > I'm reconsidering adding support for POSTs.  What's the usecase
> > exactly?  Does Twitter 302 POST requests?  If so, what's gained by the
> > application if it follows that?
> Unless I am mistaken Twitter is still doing the 302 on POST as a
> countermeasure for their DDoS problem.
> It's not that anything is gained, it's that the library doesn't work
> without it.

Reply via email to