you've got two separate problems here and it's good to NOT conflate them.
1) the interface promises you should be making
2) the internal code you need to write to honor the promises
so...
1) neither HTTP POST or PUT REQUIRE you to include any field. what drives this is how your want to frame the problem at the interface. I usually define the transitions for creation and update differently anyway (diff fields, validations, etc.) so there's no problem there. Second, I often have internal fields that are not editable for updates (IDs, critical status or date information, etc.) and dropping them from the PUT transition is the smartest way to do this. So, IME, you SHOULD NOT include fields that will always be NULL in any transition -- you're just asking for trouble<g>.
2) your code problem is a different story. if your library REQUIRES you to include NULL fields when updating, you need to put some code between accepting your POST/PUT and passing the results to your internal object model or validation code. I find most frameworks are pretty finicky about this kind of thing and are rarely useful as "direct-connections" between the interface (HTTP PUT) message and the internal object model. For this I ALWAYS write intermediaries/wrappers/translators between the external interface an the internal object code.
that's me. hope this helps.