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 <david.dellan...@gmail.com> wrote: > On Sep 1, 5:00 pm, jmathai <jmat...@gmail.com> 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.
