<p>Hey guys, I wrote this: <a href="https://github.com/derekdowling/go-json-spec-handler">https://github.com/derekdowling/go-json-spec-handler</a></p>
<p>The backstory is I've spend a LOT of time writing Ember.js applications that use Go as a backend. If you aren't aware, Ember.js >= 2.X defaults to using the <a href="http://jsonapi.org/">JSON API Specification</a> for formatting backend API requests, and for parsing responses.</p>
<p>To say the least, I got tired of implementing this over and over, and decided to take a step back and make something that I can re-use to do exactly what I need without being opinionated about routers, ORMs, middleware, etc. Right now it only handles basic CRUD actions that don't involve relationships, at least not for the JSON API Spec.</p>
<p>If you aren't using Ember, this is still a great project because it takes the guess work out of structuring both successful API response and resulting errors.</p>
<p>Let me know what you think, and if you have any feedback, thanks!</p>
<hr/>**评论：**<br/><br/>ksorco: <pre><p>Well done, but did you know about <a href="https://github.com/shwoodard/jsonapi" rel="nofollow">https://github.com/shwoodard/jsonapi</a>?</p></pre>YumYumGoldfish: <pre><p>To be honest, I didn't, they should really register on jsonapi.org! Thanks for the link. This one looks to be the best of what I've seen so far. It's interesting that despite coding in a black box, we've arrived at fairly similar design decisions and our APIs aren't that different.</p>
<p>They get points for performing fancier reflection marshaling, where as my implementation is arguably simpler, but requires two calls instead of one to get to the same place and utilizes the power of json.Unmarshal for nested structs. They also handle relationships, linking, etc whereas mine isn't there yet.</p>
<p>On the other hand, my implementation takes care of response codes, and headers automatically, which arguably ensures that the specification is being matched as closely as possible.</p></pre>ksorco: <pre><p>Awesome. I'm always slightly bummed to find out that a library already exists for something I was excited to implement. Often it's worth it anyway. I bet you learned a ton :)</p></pre>TotesMessenger: <pre><p>I'm a bot, <em>bleep</em>, <em>bloop</em>. Someone has linked to this thread from another place on reddit:</p>
<ul>
<li><p>[<a href="/r/emberjs" rel="nofollow">/r/emberjs</a>] <a href="https://np.reddit.com/r/emberjs/comments/3sl1l8/xpost_json_api_specification_made_easy_golang/" rel="nofollow">X-post: JSON API Specification Made Easy : golang</a></p></li>
<li><p>[<a href="/r/javascript" rel="nofollow">/r/javascript</a>] <a href="https://np.reddit.com/r/javascript/comments/3sl42r/xpost_json_api_specification_made_easy_golang/" rel="nofollow">X-post: JSON API Specification Made Easy : golang (Great for Ember.js, or supporting your SPA)</a></p></li>
</ul>
<p><a href="#footer" rel="nofollow"></a><em><sup>If you follow any of the above links, please respect the rules of reddit and don't vote in the other threads.</sup> <sup>(<a href="/r/TotesMessenger" rel="nofollow">Info</a></sup> <sup>/</sup> <sup><a href="/message/compose?to=/r/TotesMessenger" rel="nofollow">Contact</a>)</sup></em></p>
<p><a href="#bot" rel="nofollow"></a></p></pre>sharptierce: <pre><p>What about <a href="https://github.com/manyminds/api2go" rel="nofollow">https://github.com/manyminds/api2go</a> ?</p></pre>YumYumGoldfish: <pre><p>api2go looks okay if you're starting from scratch, and are okay with their opinions on how to structure your data and their framework.</p>
<p>If you're trying to migrate an existing library, then mine is much easier to drop into place and get the same benefits.</p>
<p>Out of the box, as of now(since I put a bunch of work into the library today) mine includes much better error handling for Input Validation and ISEs.</p></pre>sharptierce: <pre><p>will have a look, thanks for your feedback :-) but we are working on being json.(Marshal|Unmarshal) compatible currently. :-)</p></pre>
