Closed sopvop closed 8 years ago
Yes, I plan on including support for both the relationships
and included
keys. You can find issues for them at #4 and #9. Also, I'm happy to implement toEncoding
. Feel free to add an issue for that.
As far as omitting the empty keys, I hadn't planned on it as I think there are higher priority issues to complete, but again, if that's a feature you'd like to see, add an issue for it.
You're more than welcome to contribute to this project. I would appreciate the help in completing the JSON-API spec!
Support for relationships
and included
has been merged.
I've added a follow-on story #24 to improve the interface and documentation surrounding these features, but they are usable as of v 0.1.1.0
Hi,
I'm was working for some time on json api implementation for my code when you package, and finally decided to cut it out from my codebase and prepare it for hackage. And then I discovered this package.
Here are some docs, and source
I don't want to add yet another type for jsonapi document hackage ecosystem, if your existing can fit that spot.
My library mostly deals with relationships and fetching them for inclusion in resulting Document. Our document representations are quite close (I have adopted some of your stuff for it), but because of the the lack of
included
key inDocument
andrelationship
inResourceObject
I can't just switch to using your library.Are you planning to add these keys? Are you planning to implement "toEncoding" Aeson api? Are you planning to make
ToJSON
instances omit empty keys for the sake of smaller payload?