This PR ensures that we support nullable versions of all the primitive types, as well as Decimal and Decimal. I chose to only support serializing it as a string for now.

Excellent, I think this is the way to go at least now if not permanently. In a JavaScript client a conversion to number is likely to happen automatically (even accidentally) if the user wants it anyhow, so this shouldn't be a big deal.

In writing the tests for this I discovered that DateTimeOffset was not being deserialized properly.

That reminds me of a related issue I've had, I opened #45, though we may not do it at all.

I changed the language around "Primitives" to refer to "Attributes". The spec uses this term to refer to properties of a resource that aren't relationships, and I figured we should too.

Ugh...this rubs me the wrong way just because .NET "Attributes" are something completely different. However, I'm not sure that CanWriteAsPrimitive/CanWriteAsAttribute should be public (I may have done that only to facilitate testing, which of course there are better ways to do), and if it's not part of the API I don't care as much about the name. Any thoughts on changing that to private?

And sorry, my merge broke your PR, can you resolve?

Ugh...this rubs me the wrong way just because .NET "Attributes" are something completely different. However, I'm not sure that CanWriteAsPrimitive/CanWriteAsAttribute should be public (I may have done that only to facilitate testing, which of course there are better ways to do), and if it's not part of the API I don't care as much about the name. Any thoughts on changing that to private?

I've changed it to being an internal extension method, and renamed it to CanWriteAsJsonApiAttribute to make a more explicit distinction. I just don't like CanWriteAsPrimitive because that's really not what it is checking for.

Pushed new diff.