[nwg]

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.

[matttthompson]

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

[nwg]

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

There is a lot of basic http setup missing from NSMutableURLRequest that needs to live somewhere.

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

Except NSURLSessionConfiguration is more of a data type, right? By that I mean it is just a blob of parameters that can be inspected. The serializer is not just a configuration, it's something with an 'er' on the end. Plus, many of its properties are direct duplications of NSMutableURLRequest that could just be set after the fact in a wrapper function. AFJSONRequestSerializer and others suggest i follow a pattern of subclass inheritance to provide further customization when everything is just permutations on values of a core set of parameters.

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

I don't understand this argument. What's wrong with creating the simple data types for the cases you need to cover? What is the importance of the top level class count metric? Would a fourth top level data type for the raw data case suffice? Can't throttling go in a parameter of the outer configuration data type?

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

Maybe. When i look at it i see class hierarchies, singletons, and protocols with contractual state manipulation for a case that seems to (maybe it doesn't?) reduce to an output (NSMutableURLRequest) that's a straight function of a bunch of inputs.