About this talk
This talk covers the various protocols that underpin modern APIs, such as HTTP, REST, GraphQL, and WebSockets. The speaker, David Patcha, a seasoned QA consultant, presents insights from his extensive experience in API performance and security testing. He emphasizes practical approaches to testing these protocols, highlighting the characteristics of REST APIs, the complexities of SOAP, and the advantages of GraphQL, such as minimizing overfetching and underfetching of data. David also discusses the unique testing challenges associated with each protocol, including the need for documentation in SOAP and the potential performance pitfalls of GraphQL. The session is both informative and engaging, drawing on real-world examples from his consulting practice.
Full transcript
Challenge accepted. [music] Challenge Challenge accepted. Challenge [music] accepted. Challenge accepted. P2 is always [music] challenge accepted. Our next speaker has been to challenge accepted so many times that we're seriously considering giving him a permanent Bulgarian residence. >> At this point, >> at this point, he is practically family and we know exactly why he keeps coming back. It's not just the conference, it's all it's also the food.
Lutinita Paca. He loves Bulgarian cuisine so much he even adjusted his name for it. >> But beside his culinary adventures, Mr. Patcha is a QA consultant from Kakov, Poland with years of hands-on experience in API performance and security testing. >> He's spoken at conferences all over the world, written countless blog post and still somehow finds time to mentor, consult, and automate just about everything. Today he's taking
us on a journey through the protocols that make modern APIs stick from HTTP and REST to GraphQL and websockets. >> Expect practical insights, real demos, and maybe even some secret sauce for your APLs. Please welcome the person who writes code with one hand and scratches a cat with the other, >> the honorary Bulgarian from Poland, >> the one and only >> David. [screaming] Nope. Now it is.
So in terms you don't know at which conference you are here is the reminder. Uh my secret love of beta is now fully and publicly available. Um so no more secret and that's why I coming but also thanks a lot for invitation like this this event is just amazing right behind Scamba. Um so probably see you also next time. I'm not going to say it yet but
uh hopefully see you next time. Okay let's start with this actually. um now game Bulgaria uh in a final that reminds me my first ever talk at a big event and it was Poland Switzerland playing in I think it was uh European championship like play of phase and I don't remember which was more stressful like keeping life score here or talking to people probably like keeping life
score but uh that one was successful good warm-up time for you and I know in people don't want don't really like to raise your hands. So, you can scan QR code. Um, and the question is which protocols you worked with and you can Yeah, you can obviously select all of them and I hope it's going to be active. Yeah, it's working. Before we move forward, I'm really
sorry for those working with soap. Okay. Yeah, it's it's more or less as expected and uh you are the really good audience because we can give like 10 more seconds because you almost 100% match the numbers uh from Postman a little bit less or more in some protocols but that's exactly the reason why I'm going to talk about those five because they are the most popular and
the most used and actually is a really nice report if you have time to check it later um it tells much more about infrastructural stuff nowadays is more about popularity good practices so what people do and probably it's mostly based on like those very large companies But [clears throat] we know like people like to do the same. Um, and this is like quick overview and I show
this slide because I like um I don't know if I can just No, not this one. Um, there is use it and use it and love it. And there is a huge difference in the fourth one. Like there is a very very thin white uh very thin blue light blue one and WSDL is for soap as you could guess. So there is a huge difference. Everything else
is um no worries if if the if there is disconnection I speak super loudly so you probably hear me anyway. Okay. So some obviousness. The first one is uh we usually define what we do with methods like usually. The second one we define endpoints for a specific resources. The third one we have status codes. Let's not get into the details but we have them and they they
should return something. And the fourth one rest API is a wellknown standard. Um the only problem none of those is true or not entirely true and uh you will see later if you have no experience with other protocols uh what I really mean. So let's start with rest and don't stay too long here because you saw like 98%. So probably you know as well as I do
how to how to test it, how to write um code and uh this slide is going to show you the structure I want to share with you. So uh this is how the communication looks like. We have usually like some JSON that we send uh that we receive. We can send also some data or just pull a data with the pure URL. But three important characteristics I
want to mention here. Firstly is birectional. So it's request response like ping pong. We send we receive we send we receive and so on like volleyball almost. And uh if it's good game then it's good communication. The second one, our methods defines the behavior and um those quote marks like defines they are not accidental but in a let's talk about it in a second. And the third
one format usually it's JSON but uh it can be basically everything. It it can be XML. Um I put HTML here. Uh it can be just binary message whatever you want. what is important for REST and what matters for other protocols is how we build URLs. And what you see here is is probably well known like you all know this. If not then um I also do
consult consultations so no worries. Um you have URL and that defines what's going on and this is very specific for REST. Now somehow this is still very popular question. Uh what what what is post doing? Any anyone like I know it's super simple but what is post doing? Post method. Yep. yes but only if developer implements it. Post is doing exactly what the developer implements. If you
want to remove some elements from the database using post, you can do it. Yeah, you can do it like no problem. Uh it's it's very American style. You can do it like sky is the limit. It's only in your head. So if you want to build a whole product using only post methods, no problem. And that's why REST is actually not a protocol. It's more like the
set of good practices maybe even suggestions but it's not a protocol. So if you and that's why I hate this question at the interview like what post should do or actually no this is good question what should do but what is post doing yeah the cor the only correct answer from my perspective is exactly what the developer implements and this is much better to talk about those
methods in in terms of characteristics I like the fourth one is uh for many many I was somehow pronouncing it as uh impotent and uh now I'm aware of so that's good. Um but this is much better characteristics than just simply writing what is post doing and we have status codes. Um, we know that very well. The only one thing I want to mention here, incorrectly implemented
might be very misleading because what does it mean to you? 2,24. Yeah, usually [laughter] that's that's good answer. Now, uh or you you could start with it depends and that is it's always good answer. Um 20 204 usually it's there was a content and now there is no content and it's a little bit bit misleading because it's uh 200 which we usually recognize there is some data.
So that might be misleading and it's good also to have some messages uh instead of just only status codes. Um and there are obviously many potholes. Uh you you you can read it like um but the most important is this one definitely that's the biggest problem with uh with rest. There is either no documentation or documentation that is not maintained and if if we have just one
field changed it may break a lot of a lot of things and um that is unfortunately very specific for rest. for other protocols. Usually we are either forced to keep at least minimum version of of of documentation or structure. Um and that helps a lot. So boring rest. No, I mean rest is never boring unless you sleep. But uh yeah, that joke from Poland. Don't expect anything
more funny. Um soap. Now once again, sorry for those working with soap. the actually I was surprising I thought the popularity and usage is much lower like 10% maybe but it's not and the reason is in um high banking uh or financial institutions there is still soap and there is a high chance that it will be forever. So uh it will never finish because the the system
is just too complex to modify it. uh it needs to be rewritten fully and there is like Lena yesterday was was talking about business value there is simply no business value in it it's probably years of writing from the scratch if we have huge banking system using soap there is no no no no no no reason to um to change it but for those who have never
worked um actually I should start from the body but let's start from those charact characteristics is the same is request response. So we send we receive messages but we don't have methods. So like in [clears throat] like in rest we don't have methods here actually like because it's all HTTP or HTTPS communication but underneath it's post request that's that's probably on a uh on a on this
layer. And the four third one, it uses and it's not too friendly anymore. Like everyone likes JSON and not everyone likes XML and it's very overwhelming as you see the whole structure and uh it might be too small and I wouldn't see it even sitting in a first row with glasses. Um but that might be due to my age also. Um, so you see the request sent
and there is a single URL here. It doesn't change. It's always the same. Now what are pros and cons testing this? And uh it's super easy to find consurprisingly. [snorts] So it's complex because um it's relies fully on standards like SOAP standards. there is not much tooling and uh if you want to use any modern tooling like I don't know postman is probably now the most popular
for just um API communication but there are tens of uh tens of tools uh I know only one uh soap py that fully supports so soap communication I think it's marbear tool uh others you need to define by yourself like all the headers, all the structure and so on not too friendly and the reusability is not the strong also not the strong point but to be to
be fully fair I try to find some pros. Uh there are not many experts that's surely. So if you know it, you are one of only few and it learns you a lot. Who of you in other protocol had a chance to define namespaces? Yeah, probably because there are no name spaces in other protocols. And uh I started as C++ developer and that's uh that's a reminder
of name spaces like um for many many years and the first one and this is the real pro pros it's it needs some definition. So you have the we can say you have a documentation or you have at least a ref a reference what how you should build a request and what should be the response. So you are forced to keep a documentation. Now what are my
testing hints for those or testing soap protocol? The first one is because it's all about structure. You should really focus on firstly um firstly all the all the all the elements all the components but also um not like very often not like in uh in rest you have failures or all the issues coming as a separate segment of the response not as a status code. uh usual
you just get 500 and that's that's the the end but it's not too insightful to get more into details you probably need to check this one the second one is load testing and those messages are very often huge even if you have just one param to pass you need to build the whole structure of XML so it's good to test it from the performance perspective but and
that's huge but in many banks you don't care that much about performance because if you wait 10 seconds to payment be processed is it really a problem like we are used to wait at least for payments and banking systems we see this um loading or sending or waiting screen and okay we are just waiting and the third one taking care of message structure and I like what
uh Postman suggest in terms of testing XML responses First thing to do is translate it to JSON and then you can test. Uh what are the potholes? I think the biggest one and I like this um this meme on the left. If you if you have never seen and you see it for the first time, SOAP is just the same as REST but put a lot of
unnecessary stuff and send the request. Good GraphQL. Um this one this one is probably my favorite one but uh uh yeah but uh you might disagree. Um and I saw GraphQL was the least popular probably like 14% maybe only it's like um defined by Facebook and it's not young actually I I just before my talk I started thinking when it was released and it's I think 2014
so over 10 years time goes quickly and uh yeah um this is how it looks like so we send a syntax similar to um a little bit similar to JSON. It's uh predefined uh by by GraphQL um syntax of I just wonder if you can see it. Can you see it from the back? Like what is there? Okay. Okay, that's good. So you define it in that
way and you exactly define which fields you want to receive. uh but you have also the middle layer so something that communicates between client and other resources like microservices databases and so on and talking about um talking about attributes yeah it's also birectional so we request uh we send we receive but there there is also persistent connection which I will talk about a little bit later then
we have methods and it's again like underneath there is post or websockets and single URL the same as in soap and the third one we have a dedicated query format and you will receive it in JSON fortunately in a JSON format now in terms of operations we can do it's uh it's minimized comparing to what you know from rest so we have just query query is to
extract data we pull data so it's like probably get for rest and then we have mut mutations. Um for those uh in coding in JS mutations is probably self uh descriptive. So we simply mutate data. So we can edit, update or delete whatever we want. And we have subscriptions which uh gives us notification if some specific event event happens. What is the specific event? Um I will
describe in a second once we go. to websockets. So we have basically three operations we don't really have status codes. I mean we have we can see error but those errors are not too helpful many of them. Instead graphql defines own set of errors and they come as the response and the problem is us it it might very often look like this. So you get 200 but
underneath there is a problem and that's probably one of the biggest um pains in testing. So you assume it's it's fine because you always check if it's not 200 or 201 um but underneath there is a real issue. So it might look like this without getting deep into into the structure. You can send a mutation and then create a new instance of the of an object or
you can just pull data. But there is a significant risk which um should be considered in testing. So it works like that. We have an operation name get robots and then we want to get all the models and for the model we want to get the list of all the robots for this specific model. But then for the robots we want to get model and for this
robots. So we can infinitely nest those fields which uh causes a lot of issues with performance. We can we can just uh break the server very easily. So what are testing hints for GraphQL errors? As you have seen, don't rely on response codes. It's not too helpful. Better to check what's really what really comes as the response. Then queries and mutations if you don't know it is
very intuitive. If you know any query language like SQL for example that's very very intuitive. The third one complexity is the key. So uh very often the server has no limit for the complexity. So you can just uh hang hang the server. it it's fully stuck and I I've seen it a lot of uh a lot of times and the fourth one there are a lot of
helpful interfaces for testing and um which I recommend Poke API it's API for Pokemons and now Pokemons are super trendy and uh that's something I use for workshops also uh a lot of data even if you don't like Pokemons there are some nice uh nice cur curiosities about them to visualize errors the biggest issue with uh HTTP but remember that underneath there is just a regular request
and uh this middle layer usually is called Apollola server is communicating with other resources and you don't see it as a client it's just single request response but we need to move forward Now uh websockets are slightly different because it's birectional at first and it persist connection. So we connect and we exchange data. Uh so like tracking life scores usually works uh using uh you just uh
set the connection and this is the mythical 100 status you might receive because many people when you ask them if they have ever seen status 100 anything they say nope. So it's not mystery anymore if you have websockets this 100 one is usually to set a connection and then you have just messages that are exchanging. Uh the second attribute there are no methods because it's p persistent
connection that is just get to set the initial connection make a handshake and so on and in terms of format it can be UTF8 or just binary payload that is encoded or decoded on both ends if you want to save um pro uh transfer uh for example. testing hints for websockets. Uh unfortunately not as for those free before there is no simple way to do quick semi-automation
using um Postman or Bruno or any other modern tool. You either test it manually or you do just pure coding because uh none of those tools supports really automation. Uh the second one you focus you focus not only on function functional part but uh there are other attributes that um that you need to test because of the the specifics of permanent connection. So uh what is going
on if we break the connection if it's reconnecting what is the maximum size size of messages and so on. So very much on the connection layer just imagine what would you test if you have permanent connection and permanent connection might be like you call to your grandma saying hey I'm coming for a weekend could you make me cageba uh the third one don't be afraid it's nothing
nothing nothing nothing uh scary it's just different way of communication and if someone tests only like request response that might be a little bit tricky But it's not. And usually as nowadays with with AI, you can say after a day of of reading that you are an expert. There's no difference. Um but one important thing uh websockets sometimes what what I've seen at the companies to avoid
using websockets companies send and receive a lot of requests. So instead of just setting a single websocket to exchange message messages there is a 10 20 30 requests sent and received. So in terms of um optimization of uh architecture it's not the the best one and uh I told you I'm going to back to and the reason is there are websockets underneath. So this is how web
uh subscriptions works. You simply connect you have a websocket underneath and if you if you say I want to get a notification once someone orders kamachurba you get it. I know it's not funny anymore but I'm going to say it anyway. um web hooks very quickly because uh my time is almost over and it's minus01 because I think what you should know is just a structure. So
um you subscribe to an event and you wait for event like notifications on your phone usually work as uh web web hooks and it's one direction. This is intended joke for millennials and boomers. Um, so you send and forget it. Yeah, now I see who understand. Um, good. So this is quick way to check what is the age of your audience. Second one, methods like yeah there
are no methods. We just subscribe to an event and then we wait for um for messages and formats basically anything that is like text like form. It might be XML, it might be JSON. Usually it's JSON because it's it's the common standard. So what is the what are the real hints for web hook testing? Just be careful. There is no much to do and be careful otherwise
you get something like this. And uh this one on the right far right the first message it's I think from last year in in Poland and there is a new rule in Poland. If you can read it quickly now all those letters you get immediate citizenship. I don't know why it was for me but uh if someone wants to try and it's not polish you can try.
Yeah. Yeah. It's it's we have lightning talks. I can help. Um but yeah, that that's a big problem. If we send a lot of um notifications instead of uh testing environment to prod environment, this is very often ending up like this. So yeah, just be careful because web hook is like I throw it away and there is no way to stop it and if it's fraud, everyone
see it. Uh otherwise you might just wait forever and it never arrives like some my my some of my packages from DHL. Um what's next then? Well, I don't have much to say here except those hints I have gave to you. The only one is this one like learning is not compulsory but neither is survival and uh the guy William Edwards Deming actually who knows the guy.
Okay. Okay. Again it's another way of checking age of the audience. This is the guy from 50 60 years ago. He's a quality guru by the way. So if there are QAs among the audience who's QA? Um he he's quality guru but more on the industrial side. So he he wrote a lot of um I think it's like uh 12 rules of deming rules or something. I'm
not like guys working with uh with production in the factory but he was initial quality guru before there was it even. So this is the sentence I want to leave you with. Thank you very much. >> [applause] >> Thank you David. Uh unfortunately there there is no time for questions here. >> Unfortunately. >> Yeah. Okay. Is there we don't have lots of uh lightning talkers. So we
have time for one question from the there is one Uh you'll receive the mic now. and the t-shirt later. >> Thank you. >> I think you said that GraphQL might be one of your favorites or your favorite one. Why do you prefer it over everything else? >> So there is okay how many minutes I have? I have 30 minutes. So uh 30 but I might I might
make it 30 minutes. So uh quickly answering for example in um in rest there is something like overfetching and underfetching. Overfetching is when you just want to get for example ID of the person and instead you get a whole body that size for graphql you might just say hey give me this one single field. So you exactly specify what do you want to receive and underfetching is
if you want to get a specific um not set but um yeah let's call it set of data and uh one endpoint is not enough and you need to call like three different endpoints in graphql you just call it single endpoint and one structure of uh of a query and you simply wait so uh yeah for example this is one of the reasons I really like it
but there are cons of course also you need for example this middle layer to translate between client and all the resources you have um in your infrastructure so but I like it yeah it's it's uh it's very subjective but uh yeah >> thank you very much >> so David will be waiting for you in the speaker corner corner during the next uh break to ask him more
questions you want to ask Now it's important question. Okay, one more question from me and you have a t-shirt >> on the house. >> Hello question. >> That was a very nice talk David. Uh how can you um test the optimization uh performance optimization of REST? >> Oh, which one? >> REST API. >> uh performance >> yes >> of REST API. >> Yes. Um, oh my god,
it's it's >> in the speakers corner. [laughter] >> Yeah. Um, nowadays how you test it is you open chat GPT, you ask how to test performance, then you download the proper software and you copy paste the code. Uh, yeah, that's quick answer. >> Thank you very much. Once again, you can meet the vit in speaker corner in just a few minutes, in just a half an hour.
And now, let's send him off of the stage with big round of applause. >> [screaming] [applause and music]
