Alamofire: POST-ing a "body" instead of parameters?

[curioustechizen]

This is a great library that's going to make writing networking code so much simpler!

I didn't spot an easy way to POST a body of non-standard type (e.g., XML or protobuf). Would it make sense to add a way to pass in an data or a string along with a custom Content-Type header to allow this use-case?

Example:

Alamofire.request(.POST,  "http://httpbin.org/post",  data: data, contentType: "application/xml")

Alternatively, how about allowing a way to extend ParameterEncoding so that user can write their own serialization code to encode a Swift object into string etc.?

[mattt]

Most of the development and documentation of Alamofire so far has focused on the simplest, most common use cases. Right now, what you're describing is accomplished by constructing a request with an NSURLRequest. The API may change to accommodate the described method in the future.

[Jeehut]

@mattt, can't you just label this a "new feature" and leave it open? Otherwise many interesting ideas for future versions will get lost just because their state is marked "closed" which is not what issues IMHO should be used like.

What you're doing here seems to be something like "this feature is too much for the current version, so I'll close it". What I would expect is something like "this feature is too much for the current version, so I'll mark it so" and give it either a corresponding label or use the GitHub milestone feature in the first place to mark all features you agree for the first version so.

[mattt]

@Dschee That's just not how I use GitHub Issues. I give you all assurances that I know what I'm doing.

[Jeehut]

I don't wanna be disrespectful – I mean you're the one with the big experience here – but your explanation hardly satisfies my curious mind. I'm still wondering why you close ideas for future versions. I'd be happy to keep them opened or at least mark them within closed issues so that I can find them later as ideas for new versions.

But who am I to tell you something about maintaining great frameworks ... :)

[mattt]

@Dschee Feel free to conduct yourself in your work as you see fit. I'm not particularly interested in having a discussion about process.

On 2014/08/13, at 14:26, Dschee [email protected] wrote:

I don't wanna be disrespectful – I mean you're the one with the big experience here – but your explanation hardly satisfies my curious mind. I'm still wondering why you close ideas for future versions. I'd be happy to keep them opened or at least mark them within closed issues so that I can find them later as ideas for new versions.

But who am I to tell you something about maintaining great frameworks ... :)

—
Reply to this email directly or view it on GitHub.

[bpudenz]

@Dschee I like the data/content-type suggestion, as well as adding headers a little quicker than the lower level requests.

[Jeehut]

@bpudenz Me too. I was just curious and tried to learn something about process from @mattt. But he's too busy with others things. Hopefully great new frameworks! :)

[hohl]

Would like to see that too.

(+1)