AngularJS has different request data format from Jquery when send almost same post call

[wahyd4]

I was tried to use AngularJS $http and coffeescript to send a cross domain post request. I've already changed the server side to make it available for cross domain request.
The question is when I was using Angular js to send request I found the request data is different from the request sent by jQuery.

Angular

login: (user, callback)=>
    baseUrl = 'http://localhost:3000/api/v1/sessions'
    @$http({
      method: 'POST',
      url: baseUrl,
      data: {
        "user":{
          "email":"wahxxx@gmail.com",
          "password":"123456"
        }
      },
      headers:
        'Content-Type': 'application/x-www-form-urlencoded'
    }).success (result)->
      callback(result)

then I got

Jquery

$.ajax({
      type: "POST",
      url: "http://localhost:3000/api/v1/sessions",
      data: {
        "user":{
          "email":"wahxxx@gmail.com",
          "password":"123456"
        }
      },
      success: function(){

      }

Then it works well, this request data format is what I want.

I don't know whether it's an issue, hope someone can help me out.
There is same question I posted on stackoverflow: http://stackoverflow.com/questions/21400743/angularjs-cant-send-post-request-with-content-typeapplication-json

[caitp]

You're asking for x-www-form-urlencoded, and angular doesn't encode data that way currently. I suppose we could, but I'm not sure I expect that to happen. I think for the time being you should just use jQuery when you need to send requests like this, and maybe if you want to implement this feature we could look at getting it into the tree. I'll mark this as PRz welcome.

[pkozlowski-opensource]

Related to #1743. I agree with @caitp that we could easily make people's life a bit easier. I guess we could try to do is:

• detect the x-www-form-urlencoded header and serialise data accordingly
• check if data are of type https://developer.mozilla.org/en-US/docs/Web/API/FormData (but this works only in IE 10+ if I'm not mistaken)

[linclark]

Would it make sense for this functionality to live in a stand-alone module outside of core? Having it outside of core would make it easy to extend it and support other formats in the same way.

I put together a proof of concept, and a Plunker demo. If this seems like the right direction, I'd be happy to continue development on it.

[dcartertwo]

+1

[hsdk123]

From personal observation, all I need to do to get this working is to wrap the data property around with jQuery's $.param to get form posting working as it does normally.

Ex.

$http({
    url: ServerAddress+"/login", method: 'POST',
    data: $.param($scope.loginForm),
    headers : {'Content-Type':'application/x-www-form-urlencoded; charset=UTF-8'}
})

I feel it would just make life easier if AngularJS could provide an equivalent function to jQuery's $.param - ideally something that can be used also with the transformRequest property.

[daghoidahl]

+1. Coming here from the thread at #1743, I agree that this is a feature that is missing from Angular. My team was actually quite surprised to find that there were hoops to jump through to make a regular form post. In our case we have jQuery as a dependency, so we can use that until Angular has a "native" solution.

[UzEE]

Facing the same issue as well. Recently started working on a HTML5 app (Cordova) which calls a PHP backend for HTTP requests. The PHP backend is powering a number of different projects so even simple calls like login and authentication expect form-data or application/x-www-form-urlencoded.

I've really liked the bits of AngularJS I've used but this came off as a very odd omission. Even if url-encoding isn't the standard when posting data, it is the convention expected by an overwhelming number of backend services, and Angular should support it out of the box.

[caitp]

expected by an overwhelming number of backend services

lets enumerate those services, particularly the ones where this is the only possible solution and it's simply impossible to do anything else

after we've done that and established how big of a problem this is, because most people don't seem to run into this issue.

[hsdk123]

lets enumerate those services, particularly the ones where this is the only possible solution and it's simply impossible to do anything else

There's almost always a workaround to things. I don't think you'll get a service where it's literally impossible to send forms with the current Angular implementation.

As I mentioned in my post, in the end, I only needed jQuery's $.param to change my data into something my service (golang backend) could digest.

However, it did take me an extremely long time before I managed to realise the reason why my forms weren't sending and to find this workaround I'm currently using. It would be great if Angular could provide an internal function similar to $.param, or at the very least mention this problem and possible solutions in the API reference page / wiki.

[iksose]

A workaround for everything indeed, I never opened an issue because I assumed $.param was the defacto solution.

A native implementation would be great.

[paishin]

I have the exact same problem, php server does not accept OPTION method natively so I guess the problem is quite big.

I have used $http.defaults.headers.post["Content-Type"] = "application/x-www-form-urlencoded"; to switch requests to application/x-www-form-urlencoded to get the request through.

Unfortunately I do not have jQuery as a dependancy so $.param is not an option for me...are there any other workarounds?

[georgir]

There must already be a function for this in angular, as it does it for 'params' key passed to $http... but it is not publicly accessible. I think this should change and be made public, and the default transformRequest should be changed too to serialize forms according the content-type header.

For now though, if you do not want to reimplement the wheel over and over (even if its just 5 lines, I do agree it is bad news having to write it yourself), a clever trick I saw recently was to pass FormData object as data, no-op transformRequest so it doesn't get stringified as [object FormData] (offtopic, html5 spec wtf, why no adequate toString?), and undefined as content-type header so XHR.send will set correct multipart headers. For older browsers, there are FormData polyfills. Note the request becomes multipart instead of urlencoded though, often that is ok but for some backends it may still not cut it.