You should be open to using the best tools for the job, which may include both GraphQL and REST.
Treat the graph as a data-driven hierarchy defined by plural nouns: A well-formed GraphQL should look like a well-formed REST.

Don’t force GraphQL when REST makes more sense
In REST, users often request and submit data from different URLs, especially when using patterns such as Command Query Responsibility Segregation (CQRS), a design pattern first identified by Martin Fowler that separates the model that reads the data from the model that updates the data.

In GraphQL, mutations (the way a GraphQL developer submits data) can get very complex very quickly, especially when there are a lot of different data types or when very little data is submitted.

Optimize for re-usability 
In GraphQL, it’s easy to optimize for query efficiency, but be intentional about optimizing for re-usability. Avoiding situations in which APIs confuse developers will pay dividends.

#graphql #rest #apis #rest and graphql