AFNetworking alternative: STHTTPRequest

by dahx4Eev • 12 years ago

32 27 12 years ago

Greenisus• 12 years ago

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.

matttthompson5• 12 years ago

...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.

mbenjaminsmith4• 12 years ago

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.

eunoia• 12 years ago

I too always end up wrapping AFNetworking calls with an integrated (error, response) block.

I think another wonderful addition would be a client side router to match response serializers with request urls.

gbrhaz• 12 years ago

100% yes regarding a single completion/error block. Blocks are verbose at the best of times, and I find having two in the same method is a pain to look at. If there's an error, it's not nil, sorted.

matttthompson5• 12 years ago

Nothing in AFNetworking forces a success/failure block. For request operations, `completionBlock` can be set directly. For session tasks, the parameter is a `completionHandler`.

BSousa• 12 years ago

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/... (first Important block just down the page)

mbenjaminsmith4• 12 years ago

I appreciate that. I had never seen that. Of course I've never seen a case where checking for an NSError object failed either.

Although Cocoa methods that indirectly return error objects in the Cocoa error domain are guaranteed to return such objects if the method indicates failure by directly returning nil or NO, you should always check that the return value is nil or NO before attempting to do anything with the NSError object.

I wish it were a little bit less cryptic. If it's guaranteed then it's guaranteed, no? Is it possible to get a non-nil error object even after a successful call? Is it possible to have the opposite happen? Makes very little sense.

[Edited]

jurip2• 12 years ago

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...

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

richardwhiuk• 12 years ago

- 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?

faizanaziz• 12 years ago

why is that irritating.... Thats a good thing... There is no confusion of what is happening...

When there is async code the expectation is

CODE CODE [start_block { LATER - excuted in main thread }] CODE

Otherwise you write a ton of code with get_main_thread

ttflee• 12 years ago

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.

basicallydan• 12 years ago

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!

mmackh• 12 years ago

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

priyankt• 12 years ago

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

rikacomet• 12 years ago

Is the cookie implementation compliant to RFC 6265?

http://rikacomet.blogspot.in/2014/01/setting-cookies-in-perl...

nwg4• 12 years ago

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.

matttthompson5• 12 years ago

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• 12 years ago

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.

nwg4• 12 years ago

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

FWIW this is exactly what i suspected when i saw it.

matttthompson5• 12 years ago

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.

nwg4• 12 years ago

AFNetworking seems to still have too much in the way for my taste, but maybe i'm missing something. Couple of questions:

If i want to generate url requests, i have to use a serializer class. For me, it seems like overkill to have a stateful serializer. Are there a lot of cases where people change the state of the serializer once created? If not, then wouldn't it be better to just expose all the setup functionality through simple wrapper functions instead of wrapper classes, and let people layer these as they see fit (possibly with server-specific categories)?

For multipart requests, why did a protocol with appends and requiring a block with stateful appends end up making more sense than just taking an array of the parts? My impression is that it feels like a lot of chatter for multipart setup. It seems like something that could just be encapsulated as one output from a set of inputs (function). In practice, i've found this approach works better for me.

matttthompson5• 12 years ago

If i want to generate url requests, i have to use a serializer class...

No, you don't. There's nothing stopping you from creating `NSURLRequest` directly.

...wouldn't it be better to just expose all the setup functionality through simple wrapper functions?

Request serializers are not unlike any other class in Cocoa, like say NSURLSessionConfiguration, which is not often mutated beyond initial setup, but exposes properties to remain flexible and not overwhelm the user with init parameters.

What you're suggesting sounds much, much worse.

For multipart requests, why did a protocol with appends and requiring a block with stateful appends end up making more sense than just taking an array of the parts?

Not using a protocol / builder pattern here would be awful.

You'd have to create classes for each kind of part, which gets complicated because AFNetworking handles data, files, and streams alike. So that's, like, 3 extra top-level classes. And even that doesn't really work, since it makes it really difficult to just append data to the multipart body manually, in case there was some missing functionality that AFN didn't provide. Add to that the consideration of how to specify options on the stream itself, like throttling...

You should give all of that another look—it's one of the best parts of AFNetworking.

AFNetworking alternative: STHTTPRequest

Related Stories