
AFNetworking alternative: STHTTPRequest - dahx4Eev
https://github.com/nst/STHTTPRequest
======
matttthompson
I'm all about seeing new ideas about how to approach networking architectures,
but this one makes me worried for anyone who decides to adopt it.

Networking is an inherently complex problem. Attempting to simplify the
problem by ignoring those complexities, rather than actually deal with them,
misses the point entirely.

This library in particular demonstrates an unfortunate lack of understanding
of why Apple has designed its networking stack the way it has. As a result, it
needlessly duplicates interfaces and functionality of built-in classes.

Not exposing NSURLRequest means that there's no support for caching policies,
or HTTP pipelining, or setting an HTTP body stream, or control over cellular
access. Not using NSURLCredential or exposing authentication challenges means
that you lose support for digest auth, NTLM, and kerberos, and leaves the user
vulnerable to Man-in-the-Middle attacks for lack of certificate pinning and
verification. Not exposing other delegate methods means no backgrounding
support, no cache control, and no extensibility beyond what the original
author envisioned.

AFNetworking is modular and composable. If you don't want to deal with its
complexity, you can ignore a lot of it. If you don't need much, just use the
built in NSURLConnection or NSURLSession classes (they're actually quite
nice). But seriously, don't settle for a wrapper library that dumbs down a
problem; you'll regret it soon enough.

~~~
beefburger
Hi mattt, STHTTPRequest author here.

Hiding networking complexity behind a simple interface is exactly the goal of
the STHTTPRequest class.

Anyone who needs more flexibility is free to access NSURLRequest directly or
to use the library of his choice.

I keep on dreaming of something as simple as the Python's requests module for
Cocoa.

~~~
matttthompson
There's plenty of room for simplicity and abstraction, but this is not a
particularly good one, if I'm going to be honest. I can't think of any
situation in which I'd recommend this over either AFNetworking or the built-in
Foundation URL Loading system.

------
nwg
Still too complicated. IMO none these libraries should hide
NSMutableURLRequest. A lot of their functionality can and should just be
exposed as category extensions to NSMutableURLRequest and a bag of utility
functions.

We should expose composable pieces to assist with use of the existing APIs,
not build monolithic wrappers that get in our way by hiding entire chunks of
APIs in the guise of simplicity, since eventually this just requires us to
reimplement the needed abstractions in a different way once our wrappers'
limitations become apparent.

So today, it's simple. Tomorrow, since it sees more use by people with
different needs and it ends up looking a little more like AFNetworking. The
next day upstream adds some features that don't quite fit with how simple we
thought everything should be, so we twist things a little. And one day we look
up and it's all really complicated, so we scrap everything and start again
with a nice simple wrapper to hide all that stupid stuff.

And some days later, someone needs to satisfy a network requirement, but since
the authors of all of their different dependencies chose different network
wrappers (they each had an opinion about what not to expose), everything is
really hard to centralize.

------
mbenjaminsmith
I was hoping to see an integrated completion and error block as I tend to wrap
AFNetworking calls to achieve exactly that. I'm sure everyone has their
preference but I really like getting everything back in one callback and being
able to check for a non-nil error object to handle things accordingly.

I do like the idea of something simpler than AFNetworking though. While
AFNetworking is a great library it feels a bit too complex for what it's doing
at times. Depending on whether or not I need RestKit in the next project I do
I might use this instead of AFNetworking.

Thanks for sharing this.

~~~
BSousa
Since Apple advises not to use the error variable for checking for an error,
but the return value, I think the decision to have both blocks suits the Obj-C
patterns a bit more:
[https://developer.apple.com/library/mac/documentation/Cocoa/...](https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ErrorHandlingCocoa/CreateCustomizeNSError/CreateCustomizeNSError.html)
(first Important block just down the page)

~~~
jurip
That page doesn't mention blocks at all, though. Apple themselves use the (id
value, NSError *error) completion block style with NSURLSession:
[https://developer.apple.com/library/ios/documentation/Founda...](https://developer.apple.com/library/ios/documentation/Foundation/Reference/NSURLSession_class/Introduction/Introduction.html#//apple_ref/occ/instm/NSURLSession/dataTaskWithURL:completionHandler%3A)

It makes sense with blocks where you have actual multiple values you can pass
in without futzing with pointers to pointers.

~~~
mbenjaminsmith
What's strange about that is they don't (at least the few methods that I
looked at) define the behavior they're using for "combined" callbacks. Should
you check for a non-nil NSError? Is an NSData parameter going to be nil on
error?

------
Greenisus
I love this. I found AFNetworking 2.0 to be a bit overcooked (meaning it was
far more flexible, but also far less easy to learn to use; nothing against
mattt, it has really come a long way towards feeling like an official Cocoa
lib, and NSHipster is incredible...it's the first site I check every Monday).
My biggest gripe was having to start paying attention to request and response
serializers. It was nice to get "free" JSON parsing, but ending up in an error
block because of a malformed server response is a pain in the ass. Is it
really an error if you get a 200 OK response but the body isn't valid JSON? In
my opinion, not really, but anyway, I'm rambling here.

All that said, using NSURLConnection (or NSURLSession) really isn't annoying
anymore.

I'm going to give this an honest try.

~~~
matttthompson
> ...ending up in an error block because of a malformed server response is a
> pain in the ass. Is it really an error if you get a 200 OK response but the
> body isn't valid JSON?

Yes. Oh goodness, yes it is. Having consistent validation on the networking
level means not having sporadic logic scattered throughout models and view
controllers.

Your server sent invalid JSON (e.g. sending HTML instead)? AFNetworking just
saved you from a crash, or some other undefined, dangerous behavior.

AFNetworking is pedantic because networking is such a wildcard, in terms of
performance, consistency, and security.

------
richardwhiuk
> \- STHTTPRequest must be used from the main thread

> \- Success block and error block are called on main thread

Those seem like two quite irritating limitations - anyone know the rationale
behind them?

~~~
ttflee
Because STHTTPRequest was using NSURLConnection, which was scheduled to the
Main Run Loop. You can have it on threads other than the main run loop, but
you have to create the thread and kick off the run loop yourself, and manage
it afterwards.

On the main thread, you can always get a running run loop, the main run loop,
for free.

------
rikacomet
Is the cookie implementation compliant to RFC 6265?

[http://rikacomet.blogspot.in/2014/01/setting-cookies-in-
perl...](http://rikacomet.blogspot.in/2014/01/setting-cookies-in-perl-
rfc-6265.html)

------
basicallydan
I actually do find AFNetworking pretty great, but it does possibly do more
than what I normally need it to do - this looks nice and lightweight, I look
forward to giving it a go!

------
priyankt
Anyone uses MKNetworkKit? I use MKNetworkKit in most of my small projects
which has a much simpler API and works well.

------
mmackh
A very similar project for simplified network calls:
[https://github.com/samvermette/SVHTTPRequest](https://github.com/samvermette/SVHTTPRequest)
, which I actually prefer over AFNetworking. It has a super simple API.

