REST vs. GraphQL: Critical Look

Thank you, Suresh, good afternoon everyone, thank you for coming just to correct Travis a little bit. It wasn't just me last year, it was also the original hit that the business architect gave us. We had a chat together, but today we are going to talk about popular topics. These days topic

rest

and graph QL and this will be a

critical

review so my name is Zdenek Amazon o1z and I help companies create APIs. I've been at the start of the company or almost since the start of the company called APA, which was acquired by Oracle about two years ago and we had the pleasure of working with many amazing clients, starting with the small ones.

I left mash to start my own consulting company called good API because I saw the opportunity to help people on their API journey by not just telling them about the software but actually being there with them and working with them to make their API program a success. and I was very lucky to have really inte

rest

ing clients and people working with them so far. I am also the author of a super IO model which is a data modeling tool that is used to model data for API and not just API, so it works very well with QL graph and the rest, which is the current topic, such a popular topic.

I'm not going to discuss what the remainder or QL chart is, it's not everything. How important these things are in the United Nations, however, I am going to make a few things clear here and that one is the architectural style, the rest, the other is the language and the framework, both can be used to build distributed systems to build services and API. for this to be system, then I think of all of these, they are slightly different things as API paradigms and for the purpose of this review I will think of ball rest and QL graph as an implementation over the HTTP protocol because both Rest and Graph QLs can theoretically be used without HTTP using some other protocol, but for today let's stick with the HTTP caveat.

This is a

critical

review. It's based on what I learned. What I have seen with my clients. What i have seen. with my friends what I learned from running API is rest or graph API is in production and with that let's

look

at the updated reviews a bit, there are many of these articles about what is rest, what is QL graph, how they differ and many of them are saying something like rest in peace, rest, you know, hooray, QL chart, but if you

look

, you don't know, a long time ago, in the past, there were similar articles just with the different words in the headlines, it was a rest, etc. . and it was pretty much the rest, the same people were angry with web services and expected the rest to solve all the problems correctly and I really like this one that says that the rest is the new soap, so the graph shows the new rest if You have to think like this, the conclusion is that there are people happy with the current or predominant styles and they have some problems because those programs were not heard by the rest providers or the soap opera service providers, so history repeats itself and we are In another iteration of this, what I would like to emphasize is that this community is still relatively small.

I'd like to see what you know, think of us as an API community, not a Graph QL community or a REST API community. We are in one. community and we should work together to deliver good technology to humanity, but you came by blood, so we want to know which is the best, so let's look at it as you would probably expect. I'm not going. to give you the answer, however, what I'm going to do is try to give you the framework so that you can answer it yourself based on your specific environment, so I said architectural style, what is an architectural style?

Architectural style is a set of constraints that, when applied, will imply a system with certain properties. Let me explain, for example, a dekapwink constraint, so a constraint where you say my system components must be client-docked must be decoupled from the server. That implies that if that constraint is met, you can independently evolve the client or the server. I had a restriction. Decoupling implies independent evolution of both components in a similarly stateless manner. If I have a constraint that requires you to know that my communication is stateless, the state is not stored on the server that simply implies reliability scalability because I can repeat the idempotence of the call.

I can make as many calls as I want because the requests are not important and it also allows me to scale, it could be a little more, you know, the country is complicated. With these restrictions, for example, you need four interfaces on a uniform interface, which might involve decorated efficiency because you're building an interface on top of something right, so that's extra milliseconds in processing; however, it also implies simplicity because we have the same interface with two different components in the system, so constraint properties, this is the main topic today, if you are an API architect, then someone who looks at this style architectural, its main function is to understand these styles, these paradigms, the API programs and be able to choose the correct one for a given task, so the question really is not which is the best but which is the best for a given task, so to give you the answer of course you would need to know the task now before moving on to constraints and properties, let's talk about these. paradigms that we have today, so I think these are some five API paradigms that every architect, every aspiring person who is building P, should understand more or less at a minimum, so we have a web API, this is represented by API of rest consultation, now this is the one represented. mainly graphing QL, a flat file which is also an API, sharing a file with someone.

I'll get to that Streaming API and RPC API, RPC API slides. What I've noticed, but noticed over time, is that there were actually waves of these. You know, API programs were first used when we started with API in 2008. We had point-to-point, one-to-one integrations, there are specific integrations for specific partners or specific customers, usually in large companies and, as you know, the popularity grew , we begin. We got to the ESB issues and all those web services and then we had a lot of angry front-end developers and then we rested or graphically this is the generic application, it's an API provider, an API is being consumed by many clients right now.

Little by little we are reaching the next stage where we will let you know that one client does not consume one API, but there are probably many behind it and many of you are probably already consuming more than one API in your application, so little by little We're just getting to this scenario where there's going to be this many-to-many, you know, API communication and that's getting really complex and we need to automate it and then make it autonomous. I'll talk about this later this year at API Days on Paree, however the main thing is that resident graph.

QL are not the main paradigms these days if you place an order you know if you make a reservation if you order something and it is fulfilled by a logistics company if you make a payment if you buy you know plane ticket the reality is that there is very little rest or The Graph API QL runs on web services and more often also on FTP CDIs and things like this, so if you live in a bubble, rest is the main thing for a while, today you will know that it is not really the option . The paradigm should always be a function of its limitations, so this goes back to the limitations that I've been talking about and this is probably the most important slide of this talk, so I'm going to talk about colonial architecture in colonial houses, you know ?

When the Oerlikons settlers in the 18th century vulcanized America and they were building these types of buildings and they were in an environment where they had a lot of limitations around them, they didn't have the technology, they liked to fish in bad weather, right? They couldn't build a big glass window, they would probably like to have that big piece of glass, but they were just limited by the technology they had and even if they could create a big pane of glass it would probably break. You know, they transported it on horseback, so they were similar for window sellers, they had to be operational, not decoration, like wooden shutters that would close, the roof had to be steep and all that, they were building colonial houses because they were colonists and they had corneal limitations, they weren't like mmm, I really like these colonial houses.

I'm thinking I'm going to build one, guess what we're doing today? I really like the REST API for Graph QL APIs and I think I'm going to build one, that's probably not what we want to do. We have some limitations around us that we have to listen to. So what are these limitations first? I think about four hours of constraints, so first the trade constraints, this is when you think about your product what is your product what does it have to accomplish what are the tasks that you know this trade show for or it's supposed to be available for 20 years you know what are the use cases, the business requirements and also the custom related requirements, if your clients know that they can process a CSV file, good luck reaching out to them and consuming the QL graph, as you can try, you can try to educate them and , or you will lose customers or maybe you will be successful, that's it. up to you, but if you don't understand rest or HTTP or graph QL, then you might have a hard time knowing how to move them to death, so that also limits you on what you can do next, complexity constraints, for what how complex it is to do. something in the API how do you know there are different types of complexity related to this task structure related to size, how many components do you have in your system, if you have many clients making many calls, you are probably facing some complexity issues related to science which is the cognitive algorithmic complexity how difficult it is to understand you know the algorithms in that system, so what this implies and other properties, these are other constraints, then there are domain-specific constraints, so your domain constraints are where you finds. it could be some government or business regulations that you know so it can also involve some properties and finally my favorite cultural limitations and here is this Conway's law which is an amazing rule that basically says that you are intended as an organization to creating systems that are just copies or that are imitating your communication patterns if you have two teams in an organization that don't talk to each other and both teams are building some APIs, chances are they're using different paradigms and they're actually implementing, you know the same things over and over again. finished but a little bit different and it will be difficult for you, you know, to make any use of this, this application only reflects the relativity and the company between the, you know, the communication, a lot of lack of communication between the teams, there are other cultural limitations .

I like knowledge simply if you don't have knowledge if you don't understand the rest how can you build the API of the rest? The important thing here is that these constraints imply some properties of a distributed system of the product you are building, so it is not just the distributed system, but there is actually a broader ecosystem around it and we will get to that in a few, so what are they? this property, so now we had this constraint on the other side, if you apply certain constraints, you could get some properties, so let's go over some of the properties of a product distributed system that you could get based on the constraints that you're going to select first. performance there are at least three ways to think about performance there is actual network performance there is network efficiency and there is user perceived performance correct scalability this has to do with the complexity of the science of how my system scales good or not good, with many components and their many clients, which makes the cause, simplicity, another complicated property because you may not be saying "I just want simplicity", you have to ask what kind of simplicity you want, what do you want? . be simple in your product API in your API space modifyability evolvability how easy or not it is to evolve the system to make a change in the system you know that some API has taken care of this property some ApS might need other properties visibility correct this is how Well, you can see the communication between different components, so this visibility gives us the ability to, let's say, put an API gateway, a reverse proxy and between two components, so you can know how to do some things security there, etc., caching, of course, ability to move. your code with data deployed in different environments reliability these are some properties and in reality those problems are just explosive, it is promised that they will be induced by the architectural style of rest, there are other properties that are relevant these days that are notnecessarily covered by the break, such as discoverability, how it is easy to discover the actions available in the API, but not just the action within the API, but how you can find that API.

I look forward to navigating the API landscape. Security type. Ease of development. Those are some of the properties that may interest you. You may not care it depends and of course the profitability. There's this ecosystem around the system that you're building, that you might be interested in and its properties, how active the community is, how good it is at bonding, but it's the bulk of the entire ecosystem. and systems actually, including resources, articles, books, presentations, onboarding and tutorials and last but not least how ready it is to be implemented in the company, these are some of the properties that matter to me. in general, not for all APIs, if you have come to me and said, I want to create a product for this and this, you may not need all these properties to deliver that product, these properties are too broad to be necessary for all APIs, most likely If you are creating an API that will be here only for the next few weeks, then you don't need availability, you don't need to modify it correctly, its constraints will result in different properties, so we always need to think about what it limits me.

What am I doing? What is my team capable of? If you know that only Java developers use a certain framework, am I going to teach them something different? Or you know, do it in that framework and do it quickly. What is most important to me? market or you know that you are benefiting from some other properties of the system, but you should choose according to your choice regardless. Now I am trying to do a critical review of these architectural styles based on the properties you are getting. In general, if you use them, the first break it's very difficult to start with the break if you don't know what the break is and you're already here in 2018, maybe there are too many resources or maybe there are too few resources that are concise, you know how to talk about what is the rest.

There are some groups that are trying to solve it. API Academy here has good tutorials, but I'd still say the rest is hard to learn and even harder to master. It took me a long time to get it, at least you know something. true, and these APIs are rare to find, they are very difficult to find outside of the World Wide Web because the World Wide Web is the largest and most successful implementation of a REST API; however, if you extract the rest of the API correctly, you will get scalability and evolvability and discoverability like no other architectural style and you can say this is proven by the World Wide Web, so here is the original list of limitations that comes with this architectural style that we call rest.

I'm not going to read them. the promise is that if you follow these constraints you will get those properties in the distributed system on the right hand side, that's the promise and that's all the rest, it doesn't give you anything else, it doesn't give you the framework, it doesn't give you format anything , you just tell it these constraints that it follows and it will get them, so rest has benefits, like I said it scales indefinitely, at least as far as we know, so far it's pretty efficient, especially if you use HTTP 2 for the call and it's tested during decades. works with any representation with any media type which is also good and it's foreign focused so it has a high design maturity because the rest API is designed around the actions you can perform there and it's driven by the state of the application and allows this. evolution over time has a hard cost to learn it's a big paradigm shift in the environment when you have web services it's hard to explain you know the web service is moving towards rest it's a pretty big mental step that requires you customers play along which is also one of the types of drawbacks and arguably it's not so good to link the challenge of doing some governance with the risk, so we have this core group that I call the rest APIs, so Now, if you wanted to ask, what are they?

Are you talking about there being a lot of rest APIs? Well, the truth is that there are very few. The rest I call rest API. It's like we're not going there. It's the most common style of API we have these days and usually these. APIs follow HTTP restrictions, so what you get from the HTTP protocol, if you follow the HTTP protocol, you get those restrictions and therefore those benefits. However, not all APIs follow the HTTP protocol, so things like you know when using the right verbs refer to separating metadata. data, etc., these are the things I'm talking about and they're actually described very well in the Amazon and Richardson maturity models.

This API call still requires a fairly extensive understanding of HTTP to populate Chrome correctly and give you scalability. These are the original restrictions of the rest, but this API generally does not come with such descriptive and high messages, which means Hyper media, which implies that you do not get those properties, you do not get the simplicity of the uniform interface and you know. you're getting, you're not getting the ability to modify, in other words, it's very difficult to evolve this API, so if you were ever thinking about version control and all this, if you were at the conference listening to some versions, they told you that this was because you didn't flow everything.

You don't have the ability to modify these restrictions so I've already reviewed this so again it may still be quite effective but it also takes some learning especially at the HTTP protocol level and they are practically impossible to develop, sorry they evolved over time. so the QL ap graph is, again, the graph, the language and the framework, a lot of nice libraries and tools and this makes the most specific much more specific than the rest and then Wiseman said the more specific you make something, you know which will probably be accepted or a lot. for people, this is what we're really looking at here and for the good graph, it's very easy to get started with QL.

Basically it is about eliminating access to data. These are things we have seen before. It's like SQL over a distributed network, but your provider is better. Agnostic so far and of course it's pretty stripped down for SQL, but it's good because it can offer an unmatched developer onboarding experience and time to market. You're wasting two things, but few things because you usually tunnel through the post and right now you have a lot of back shedding, so the things that were already invented for the other architectural hiding place that need to be reinvented here don't matter. and hopefully eventually they will happen, but right now if you jump into that, you're not going to get things like you know the tile authorization authentication content.

Negotiating things like this you basically have to fix yourself and there are also scalability issues because Graph QL doesn't support or take advantage of the caches we have for the Internet and the World Wide Web, so again it comes with benefits in user experience and time to market. . Really very good things. I'd love to work with Graph QL APIs, but it's also surprising that it naturally relies on contracts with rest or the REST API call we're advocating. Please start with the contract first. Write the API description first before developing with Graph QL. you have to do it, so that's very good, but again it has some costs, the client and the server are coupled, it's hard to evolve independently, there are a lot of cycling trigger issues with scaling.

I'm trying to put this in a large table, which is a lot of columns, so it didn't fit here. I'm going to share it. I'd love to hear your comments and thoughts and maybe know what you think should be different, but this is like a scorecard on different of these properties comparing the stars. I'll post it later on Twitter. Another thing I want to mention: there is no way to escape API design with the rest. You had to think in advance about the use cases for what you want. you are designing, you have to understand what people want to do with your API design with the QL graph.

Apparently you don't have to. Basically, you just provide generic access to a data set and everyone will pick up what they want, well in reality. is that's not so true because then someone starts doing really graph abusers to make really complicated queries that screw up your system or make it really slow or you know the service will crash so you need to start optimizing the queries that They don't allow certain queries like this, so at the end of the day you have to understand what users are actually doing or what they want to do. The difference is that with the rest you must do it first to have a good design with the QL graph.

You can postpone it. until later, but you'll still have to think about it, so there's no escape. Do you know how to design a good API? Do you know how to understand these user cases? Then you have to make design decisions. So I would like to end with Some examples and this is my favorite company and we had a lot of success with our API evangelism. We even had the HR team come to us and say, "Hey, we heard there are these APIs. We want to have a REST API, let's build one." ok, ok, so we started and designed a really good REST API and then I asked more and more about the use cases and we realized that basically what they wanted to do they had this right third-party payroll processing provider company and what they wanted.

What you really need to do is just give them once a month all the employee records, they will batch process them and do something with the payroll correctly. This is a very bad example of a real-time API, so you probably just want to hand them that big fat file. and you know, every once a month, so all I'm saying is that continuing to share a file might be a viable option, it depends on what the use case is and you have to think about it like there's no point in doing a However , the REST API is a good case for a graphical QL API when you talk to yourself.

I really like that you know what Gatsby Jas is doing which is a static site generator but it still gives you very nice access to the static data via a graph QL API and if you don't need the money there then this It's just amazing. What I would say you want to use is what we are doing in our data. We had a lot of APIs there, let's say there is a product. API and you learn about your shoe, what is the information about that particular product, but then you want to link it to another API and find out what is the availability in the b2c inventory, b2b inventory, how does it relate to your reference data API?

So if so, if you have this API landscape where you have multiple APIs, then I think rest is actually a very, very good option because you can link the APIs and you know, follow the links from home, this is a product, was it availability, etc., etc. and I also think rest in general is a very good thing for microservices because you know they're naturally bounded contexts and you're navigating and mapping between them, so use rest if you want to build a system that will last if you need the content. negotiation if you want precise authorization to indicate rate limiting or interconnect APIs or use mixed media types or worry about scaling if you are building a system there will be many components then use the rest use the graph well if you are talking just back to the front in scenarios, that one is very good, use it instead of the so called rest, please don't do that anymore, luckily we now have QL charts for short term projects, uncertain use cases when you need to iterate on the product January and you need to figure out what those users really are or you're just going to provide access to the data without the need for infrastructure education or lolly wolly.

This case is an amazing developer experience with very little effort. Don't do this with the REST API call, but Always choose based on your limitations, not someone else's, because you are unique, thanks, great Z, don't go too far because we have five minutes so I might take a moment to ask questions to the audience, yes, we have some super confusing ones. Ted wanted to ask about contracts because you said that the contract is a natural part of the QL graphic design paradigm. Can you explain that? A little thanks for how the contract is or how I define it.

The description of an API. What is API? is a map for the API and the QL graph, you should have it because it is a graph, your schema says what the API offers, what are the actions, what are maybe the mutations or potentially what queries you could make and what are the data of the contract. here it means and that applies to both graph API and REST API is a contract it's basically a arrogant API description for REST API or graph your schema for graph APIs and once you define it, hopefully at the startof the development and the QL graph you have to do That's the beauty of this at the beginning of development or before development, then you should link to the parts in the API lifecycle so that customers know what they can expect once they things are implemented, stakeholders know what is being implemented. be tested or driven by this, the contract concept works in both worlds, but with QL graph you absolutely need to have it, there is no QL graph API without graphing your schema, yes, so the graph protocol is the contract, in a way your schema chart is the contract once once it's approved like it's Recker it's a contract if it's approved you know you write the arrogance on the QL chart people look at it say hey this is what we want to consume what we want to build yes, let's do it at that time the contract becomes, oh, thanks, sure, great question.

I think we have time for one more. Any interested, yes, way out there sir, so think about the limitations of the environment you are in and the properties you visited again, so I have a question about the linking. Yes, that's a challenge sometimes when you have distributed microservices that aren't supposed to know about each other. Do you have a strategy? Yes, very good, first there has to be a willingness to understand that if I have this, let's use this little example, probably the API with the information about the shoes of the item, then you have another API that could have information about the availability of the product point, normally you would have no idea about this item in this API.

I put it in some you know, request another API and I'll get the availability. What I'm discussing here with the REST API is that you can link from this probably the API to this inventory API and there has to be microservices this microservice discovery, the URL of course has to resolve and it has to be a known host, so which depends, there are some microservices discovery tools that you know that can help you with that, but first you start with this determination that you want to link between APIs and this is what made the web and Google possible because web pages were not linking within the site but across different sites.

Very good, super Zee, even without a co-host. Well done, thank you. Take one more round. of applause thank you