6 ms·

AFNetworking alternative: STHTTPRequest

32 points by dahx4Eev 12y ago

Greenisus 12y 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.
- matttthompson 12y 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.
mbenjaminsmith 12y 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 12y 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 12y 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.
  - matttthompson 12y 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 12y 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/Conceptual/ErrorHandlingCocoa/CreateCustomizeNSError/CreateCustomizeNSError.html https://developer.apple.com/library/mac/documentation/Cocoa/... (first Important block just down the page)
  - mbenjaminsmith 12y 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]
richardwhiuk 12y 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?
- deleted 12y ago
  [deleted]
- faizanaziz 12y 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 12y 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 12y 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 12y ago
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.
priyankt 12y ago
Anyone uses MKNetworkKit? I use MKNetworkKit in most of my small projects which has a much simpler API and works well.
rikacomet 12y ago
Is the cookie implementation compliant to RFC 6265? http://rikacomet.blogspot.in/2014/01/setting-cookies-in-perl-rfc-6265.html http://rikacomet.blogspot.in/2014/01/setting-cookies-in-perl...
nwg 12y 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.
matttthompson 12y 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 12y 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.
  - nwg 12y 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.
  - matttthompson 12y 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.

32 points by dahx4Eev 12y 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.

matttthompson 12y 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.

mbenjaminsmith 12y 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 12y 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 12y 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.
- matttthompson 12y 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 12y 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/Conceptual/ErrorHandlingCocoa/CreateCustomizeNSError/CreateCustomizeNSError.html https://developer.apple.com/library/mac/documentation/Cocoa/... (first Important block just down the page)
- mbenjaminsmith 12y 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]

richardwhiuk 12y 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?

deleted 12y ago
[deleted]
faizanaziz 12y 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 12y 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 12y 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 12y ago

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.

priyankt 12y ago

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

rikacomet 12y ago

Is the cookie implementation compliant to RFC 6265? http://rikacomet.blogspot.in/2014/01/setting-cookies-in-perl-rfc-6265.html http://rikacomet.blogspot.in/2014/01/setting-cookies-in-perl...

nwg 12y 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.

matttthompson 12y 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 12y 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.
- nwg 12y 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.
- matttthompson 12y 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.