What does it take to design a good API? Let’s take a look at that question by considering some of the mistakes that developers commonly make when creating APIs.
Error 1: Inconsistent APIs
Consistency could be defined as “agreement or harmony of parts or features to one another or a whole”. When you design an API, it signifies that you keep your decisions aligned to a single line of thought in several aspects.
First, naming conventions […]
Read More →
Do you like the look of GraphQL, but have an existing REST/RPC API that you don't want to ditch? GraphQL definitely has some cool features and benefits. Those are all bundled in one package, with a nice marketing site, documenting how to do all the cool stuff, which makes GraphQL seem more attractive to many.
Obviously seeing as GraphQL was built by Facebook, makers of the RESTish Graph API, they're familiar with various endpoint-based API concepts. Many of those existing concepts were used as inspiration for GraphQL functionality. Other concepts were carbon copied straight into GraphQL.
Facebook has experimented with various different approaches to sharing all their data between apps; remember FQL? Executing SQL-like syntax over a GET endpoint was a bit odd.
Facebook got a bit fed up with having a one-endpoint-based approach to get data and this other totally different thing, as they both require different code. As such, GraphQL was created as a middle-ground between endpoint-based APIs and FQL, the latter being an approach most teams would never consider - or want.
That said, Facebook (and others like GitHub) switching from RESTish to GraphQL makes folks consider GraphQL as a replacement for REST. It is not. It is an alternative.
Whilst the use-cases for the sort of API you'd build in GraphQL are quite different from those you'd build with REST (more on this) or RPC, that...
Read More →