In our most recent everis UK innovation session, we debated the topics of Hybrid Integration Platforms (HIP), the history of application integration and how iPaaS solutions are revolutionising the integration landscape nowadays.

The most intriguing discussion was whether REST can actually fit all purposes or if there are better integration styles out there for us to embrace.

In this series of 4 posts, I’ll be exploring the new kid on the block – GraphQL and whether it could be the new GraphQL or not. However, before starting with GraphQL, let’s look into the most relevant pros and cons of the current state-of-the-art “RESTful” style:  


  • Based on pure standard HTTP protocol, with no actual add-ons, making it highly interoperable
  • Less verbose than previous popular standards like SOAP, bringing also JSON into the spotlight
  • Easy to implement for both publisher and consumer in many platforms and technologies
  • It can be message-driven or event-driven, depending on the architectural style selected for the entire solution
  • Enforces a list of principles and best-practices, including the right use of HTTP verbs, resource-orientation, HTTP error codes and HATEOAS, to name just a few


  • It is resource-orientated which makes it suitable for CRUD operations over a single resource, but struggles when dealing with many resources and non-CRUD operations such as complex queries, validations or notifications. REST can be tweaked to accommodate any of these, but breaking substantially the RESTful principles
  • HATEOAS is great for browsing and/or paging, it can actually become verbose. To retrieve an entity and a list of sub-entities, you may have to invoke N+1 REST services
  • HTTP verbs are understood by everybody when talking about GET or DELETE. But what about POST, PUT, PATCH or HEAD? API Analysts use them indistinctly, so it’s not clear for consumer what a specific method will actually do
  • On the attempt of just working with the HTTP specification, it ended up being non self-documented.
  • Customisation of REST services is not trivial. If two consumers need slightly different pieces of information when retrieving resources, we need to duplicate endpoints and force the principle to accommodate these differences.
  • RESTful is just an interface and doesn’t offer any help with its backend implementation, which needs to be written from scratch.

The list continues, but the above can be recognised as the most relevant.

The next question to ask is, So what is GraphQL and where does it come into play?

In my next post, we’ll delve into this topic. To make sure you don’t miss it, subscribe to receive a notification here.