I find life is generally easier when I keep the keys in attributes identical to the keys that the server sends/receives. That said, giving people the option to do what they already can with save (POST/PUT) + toJSON in the save (PATCH) case seems reasonable, though their end of the code may start to get unwieldy.

Totally agree. I personally wouldn't do this, but I think we shouldn't stand in the way if you want to do it in your code.

Agreed, and agreed. Thanks!

Hello,
I don't know if I should be posting here or opening another issue.

I would like to suggest another way to handle this case, because the solution implemented in this PR implies bad separation of concerns:

• I think the model should be responsible for converting the representation to and from the server.
• This PR forces the caller to supply the server-side representation.

It is also inconsistent, as sync() and save() must be supplied the server-side representation when using the PATCH verb but not when using the PUT verb.

A possibly better approach could be:

• add an optional argument for toJSON, specifying which attributes to serialize (if argument is not set, serialize everything as usual).
• in sync(), always use toJSON before sending data. When patch option is true, pass it _.keys(attrs) as a list of attributes to serialize.

This way, the save() and sync() would be consistent in their patch/non-patch behavior, and the knowledge of when and how to convert the representation into server-side representation would remain encapsulated in the model.

Please tell me if I should open another issue, rather than adding to this one ^^