![]() The main advantage GraphQL brings over REST is decoupling the retrieval of data from where it’s located on the backend. GraphQL Brings Many Improvements Over REST With this in mind, let’s look at why developers may prefer GraphQL and why REST will still be around for a long time into the future. It’s crucial, therefore, for the CMS to give developers the option to use whichever technology is best suited for the task. It’s nearly impossible for CMS vendors to predict how companies will use their APIs, especially with omnichannel content delivery becoming the norm. That’s why many software vendors are offering support for both. The standardization that GraphQL provides also brings limitations that only REST APIs can surpass. If you're interested in learning more about what defines these considerations, feel free to check out the following video.While the advantages and disadvantages of both REST APIs and GraphQL have been hotly debated in recent years, the reality is that both approaches have their uses. The primary concern should always be to design an API that interacts with a capability, and to make sure that it is designed with the end-users in mind. Design APIs Properlyĭon't let your choice be dictated by the tools or whichever method is easiest to create an API. GraphQL was designed to be used as an API between UIs and APIs in data-centric settings, and it can be a good choice for that situation. Listen to ConsumersĪPIs are designed and provided for consumers, so it is important to think about who will be using the API. REST will often serve as the better option in this scenario. Other APIs are more workflow-centric, allowing users to have process-oriented conversations with the API. GraphQL can be an appropriate choice in that instance. Some APIs are more data-centric and primarily provide access to data. Consider how your API fits into that environment, and how both your own and the overall field may evolve. Your API will not often exist in isolation. These four considerations provide a useful starting point for that decision: But it's interesting to debate which considerations, your constraints, are most relevant when choosing between the two options. After all, " design depends largely on constraints". Which one is the right choice for you?Īs is the nature of design, that question lacks one definitively correct answer. ![]() There are various situations today where users will be choosing between REST and GraphQL. The public Facebook APIs are still resource-oriented REST APIs. It is interesting to consider that even today, Facebook uses GraphQL only for their internal API to connect their own front- and back-ends. ![]() However, Facebook chose an entirely different API style and created the query-style GraphQL language as an alternative. They could have created more coarse-grained resources with additional filtering capabilities. One overhaul option for their internal API, which connects Facebook apps on the phone and in the browser to their back-end, would have been to change the design of the REST API (resource-oriented HTTP-based API). This prompted Facebook to return to the drawing board and modify its internal API. ![]() GraphQL began when Facebook observed that the HTTP-based API powering their UIs was too chatty and did not allow more specific requests in efforts to avoid overfetching. GraphQL" debate, it is useful to look at where GraphQL originates. In order to better understand the "REST vs. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |