What is JSON API and what are its top alternatives?
Top Alternatives to JSON API
- REST
An architectural style for developing web services. A distributed system framework that uses Web protocols and technologies. ...
- GraphQL
GraphQL is a data query language and runtime designed and used at Facebook to request and deliver data to mobile and web apps since 2012. ...
- OpenAPI
It is a publicly available application programming interface that provides developers with programmatic access to a proprietary software application or web service. ...
- OData
It is an ISO/IEC approved, OASIS standard that defines a set of best practices for building and consuming RESTful APIs. It helps you focus on your business logic while building RESTful APIs without having to worry about the various approaches to define request and response headers, status codes, HTTP methods, URL conventions, media types, payload formats, query options, etc. ...
- Oracle PL/SQL
It is a powerful, yet straightforward database programming language. It is easy to both write and read, and comes packed with lots of out-of-the-box optimizations and security features. ...
- Oracle PL/SQL
It is a powerful, yet straightforward database programming language. It is easy to both write and read, and comes packed with lots of out-of-the-box optimizations and security features. ...
- Prisma
Prisma is an open-source database toolkit. It replaces traditional ORMs and makes database access easy with an auto-generated query builder for TypeScript & Node.js. ...
- Graphene
Graphene is a Python library for building GraphQL schemas/types fast and easily. ...
JSON API alternatives & related posts
related REST posts
- Schemas defined by the requests made by the user73
- Will replace RESTful interfaces62
- The future of API's60
- The future of databases48
- Self-documenting12
- Get many resources in a single request11
- Ask for what you need, get exactly that5
- Query Language4
- Evolve your API without versions3
- Fetch different resources in one request3
- Type system3
- GraphiQL2
- Ease of client creation2
- Easy setup2
- Good for apps that query at build time. (SSR/Gatsby)1
- Backed by Facebook1
- Easy to learn1
- "Open" document1
- Better versioning1
- Standard1
- 1. Describe your data1
- Fast prototyping1
- Hard to migrate from GraphQL to another technology3
- More code to type.3
- All the pros sound like NFT pitches1
- Works just like any other API at runtime1
- Takes longer to build compared to schemaless.1
related GraphQL posts
I just finished the very first version of my new hobby project: #MovieGeeks. It is a minimalist online movie catalog for you to save the movies you want to see and for rating the movies you already saw. This is just the beginning as I am planning to add more features on the lines of sharing and discovery
For the #BackEnd I decided to use Node.js , GraphQL and MongoDB:
Node.js has a huge community so it will always be a safe choice in terms of libraries and finding solutions to problems you may have
GraphQL because I needed to improve my skills with it and because I was never comfortable with the usual REST approach. I believe GraphQL is a better option as it feels more natural to write apis, it improves the development velocity, by definition it fixes the over-fetching and under-fetching problem that is so common on REST apis, and on top of that, the community is getting bigger and bigger.
MongoDB was my choice for the database as I already have a lot of experience working on it and because, despite of some bad reputation it has acquired in the last months, I still believe it is a powerful database for at least a very long list of use cases such as the one I needed for my website
When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?
So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.
React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.
Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.
related OpenAPI posts
We use Swagger Inspector in conjunction with our universal REST-API "Charon". Swagger Inspector makes testing edge-cases hassle-free and lets testing look easy. Swagger Inspector was also a great help to explore the Mojang-API, that we are dependent on, because it is the central repository for minecraft-account-data.
We previously used Postman but decided to switch over to Swagger Inspector because it also integrated seamlessly into Swagger UI, which we use for displaying our OpenAPI specification of said REST-API.
- Patterns for paging, sorting, filtering7
- ISO Standard5
- Query Language3
- No overfetching, no underfetching3
- RESTful3
- Ask for what you need, get exactly that2
- Get many resources in a single request2
- Self-documenting2
- Batch requests2
- Bulk requests ("array upsert")2
- Resource model defines conventional operations1
- Evolve your API by following the compatibility rules1
- Resource Modification Language1
- Overwhelming, no "baby steps" documentation1
related OData posts
Oracle PL/SQL
- Not mysql1
- Massive, continuous investment by Oracle Corp1
- Multiple ways to accomplish the same end1
- Extensible to external langiages1
- Pl/sql1
- Powerful1
- High commercial license cost1
related Oracle PL/SQL posts
Oracle PL/SQL
- Not mysql1
- Massive, continuous investment by Oracle Corp1
- Multiple ways to accomplish the same end1
- Extensible to external langiages1
- Pl/sql1
- Powerful1
- High commercial license cost1
related Oracle PL/SQL posts
- Type-safe database access10
- Open Source9
- Auto-generated query builder8
- Increases confidence during development6
- Supports multible database systems5
- Built specifically for Postgres and TypeScript4
- Productive application development4
- Supports multible RDBMSs1
- Robust migrations system0
- Doesn't support downward/back migrations1
related Prisma posts
I just finished a web app meant for a business that offers training programs for certain professional courses. I chose this stack to test out my skills in graphql and react. I used Node.js , GraphQL , MySQL for the #Backend utilizing Prisma as a database interface for MySQL to provide CRUD APIs and graphql-yoga as a server. For the #frontend I chose React, styled-components for styling, Next.js for routing and SSR and Apollo for data management. I really liked the outcome and I will definitely use this stack in future projects.
In my last side project, I built a web posting application that has similar features as Facebook and hosted on Heroku. The user can register an account, create posts, upload images and share with others. I took an advantage of graphql-subscriptions to handle realtime notifications in the comments section. Currently, I'm at the last stage of styling and building layouts.
For the #Backend I used graphql-yoga, Prisma, GraphQL with PostgreSQL database. For the #FrontEnd: React, styled-components with Apollo. The app is hosted on Heroku.
- Will replace RESTful interfaces0
- The future of API's0
related Graphene posts
We recently switched from MongoDB and the Python library MongoEngine to PostgreSQL and Django in order to:
- Better leverage GraphQL (using the Graphene library)
- Allow us to use the autogenerated Django admin interface
- Allow better performance due to the way some of our pages present data
- Give us more a mature stack in the form of Django replacing MongoEngine, which we had some issues with in the past.
MongoDB was hosted on mlab, and we now host Postgres on Amazon RDS .
We recently implemented GraphQL because we needed to build dynamic reports based on the user preference and configuration, this was extremely complicated with our actual RESTful API, the code started to get harder to maintain but switching to GraphQL helped us to to build beautiful reports for our clients that truly help them make data-driven decisions.
Our goal is to implemented GraphQL in the whole platform eventually, we are using Graphene , a python library for Django .