Access and Feeds

API Evolution: Advantages of GraphQL APIs in Data-Centric Applications

By Dick Weisinger

There is an architectural debate happening now on the pros and cons of two competing API technologies: REST and GraphQL.

REST APIs superseded older APIs for querying servers like CORBA and SOAP. Those older technologies were very complex and difficult to use and debug. The history goes back twenty years when REST was first introduced and picked up on by companies like eBay.

The landscape is changing again one more time. Facebook introduced GraphQL because REST requests tend to be too blunt and not able to easily request very specific data. REST data responses tend to be bloated and return far more data than may actually be needed. GraphQL particularly shines in use cases that are very data-centric because it features a query languate that lets you request specific fields from multiple data objects.

Martin Buhr, CEO and founder of Tyk, wrote that “to use a metaphor, REST is like a menu in a good restaurant, offering a small, but high-quality selection. GraphQL is like the kitchen: a pantry full of exotic ingredients where the chef has the control to pick the right ones to create and innovate as they desire.”

Anant Jhingran, CEO of StepZen, said that “the paradigm shift really is about the importance of frontend developers, and developers who drive experiences. And the developers who drive experiences are working in these new JavaScript technologies and React technology and others. But they are driving towards this kind of complete abstraction and saying, ‘look, we only care about the data, and we don’t care about how the data is produced and everything else.’ And GraphicQL turns out to be a fantastic kind of new train [of thought].”

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)

Leave a Reply

Your email address will not be published.

*