Allow the data argument to be a string

[joshuajabbour]

Since data must be passed as an object, there is no easy way to get form data and pass it into the ajax request (say on a form submission, with data using jQuery.serialize()). The magic arguments parsing in Resource.prototype.extractUrlData seems to make this impossible to fix.

Anyway, I'm not sure how to get around this, but form submission seems like a fairly common rest api necessity.

[joshuajabbour]

Something like this should be used in case someone else is trying to get around this issue: https://github.com/danheberden/jquery-serializeForm

[jpillora]

Edit - $(this).serialize(); returns a string so you must use plugin mentioned above.

$('form').on('submit', function() {
  var obj = $(this).serializeJSON(); //using aforementioned plugin
  client.api.foo.update(obj).done(...);
  return false;
});

[joshuajabbour]

Did you try your example? It definitely doesn't work, which is why I opened this issue.

As I said, Resource.prototype.extractUrlData only accepts an object for data, so you can't use an encoded string (such as the one you get with jQuery.serialize() or it will get treated as params and added to the query string (it could also get treated as an ID if you didn't provide the requisite number).

And yes, as I mentioned, there are plenty of plugins to help with this, some of which are here in this list. But the user has to realize they need this. I spent a considerable amount of time today trying to figure out what wasn't working, as sending form data is a core use case for ajax integration. I eventually figured it out by stepping through the source code (which was more difficult than it needed to be due to the overly-verbose coffeescript generated output).

Anyway, at the very least, please document this limitation.

[jpillora]

Ah yep misread your initial comment, my mistake. data should indeed be allowed to be a string, though it would be difficult due to the current overloading magic. Since there are N id strings. As a simple fix, we could add more magic: {$value: foo} silently becomes foo. With a bit of work, we could add a real fix. Since:

create - POST /foo
read - GET /foo/:id OR GET /foo
update - PUT /foo/:id
delete - delete /foo/:id

Only read needs optional argument, for the other verbs, the number of arguments required will be known. So for non-GETs, instead of type checking we could count arguments: Grab N ids, then data, then queryparams.

Only thing is I don't have time to make this change, so I'll reopen and mark for PR :) Also see #27