Hacker News Reader

Comment by kaidon | Hacker News Reader

jsonapi solves some problems, and introduces so many more. As a standard intended to reduce bike shedding, I have never had as many bike-shedding discussions as I have with jsonapi. Include syntax, plural vs single resource naming. sorting syntax... the list goes on. And worst of all... you cannot represent an API backed by jsonapi with swagger/openapi... a more common standard.

If you want jsonapi, you probably really want graphql...

View on HN

If you're comparing JSON:API to GraphQL then yes, there are some more decisions to be made, like filtering and sorting. (Includes are well specified in the spec- what bikeshedding were you doing?) But compared to not following a standard, you were going to have to make those decisions anyway.

> ou cannot represent an API backed by jsonapi with swagger/openapi

This doesn't seem right to me. What issues were you having trying to specify a JSON:API service using OpenAPI?

Well, that might be true when implementing from the scratch, but using a standard often also means, that someone has implemented a well known library to get rid of the boilerplate and basic decisions.

I personally often use jsonapi.net[1], a C# implementation of JSONAPI. This supports OpenAPI/Swagger with swashbuckle, has a very good filtering implementation and together with Orbit.js[2] it is pretty much without having to decide too many things...

[1]: https://www.jsonapi.net/

[2]: https://orbitjs.com/

Reply on news.ycombinator.com