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