 You here will learn new things about JSON API and for those who have already heard about JSON API, it will cover some things that will be interesting and relevant to you, I guess. Okay, so I'll be talking about JSON API and how to make it a compliant API. There's always this term called compliant and which they always use in enterprise places. No worries, this is not about enterprise staff and we're not going to kill someone over not having a certification for whatever not. My name is Huiren and my Twitter is down there at WuHuiren, you can follow me. I tweet about things like Angular, Node and PHP as well and I've got this tagline I always like to use. Proprietary softwares was nightmare and when people heard of that, they'll be thinking like, oh, it must be Richard Storman or some Nick's Extreme Riot or some things like that. But no, well what I do as a, I'm actually a Fedora ambassador so I help to organize various events such as document freedom day. Anyone heard of it before? Okay, that means I'm doing a bad job. Yeah, and of course I was an open organization ambassador where I convinced or at least try to convince people that there are no tag problems. The problems always lies with social problems and people are the problem. And people don't really understand why because they think I'm a hateful person and I hate people and antisocial and stuff but well I'm okay with that. I write articles that share about how do you deal with open management, how do open source communities work in such a complicated way, how do they even survive and thrive? Right, well I also do some side projects such as MPVPN. It's a VPN within the Nian school itself and you can't really play multiplayer games in the school. Oh, by the way, I'm from Nian Poly so I created this VPN for people to actually play games in school, right? So it's a freedom and hopefully the teachers will still like me. And I really like cats too so you can see there's a lot of cats there. Okay, well throughout my journey so far I've got several inspirations model from my friends, right? So these three friends of mine, first one is Phil. He's from, I met him last year in Fox, Asia. He's currently one of the core contributors to the Stout Components and he's a very active, reactive person, right? So he does React.js. And Josh Long, I met him at one of the spring meetups I think a few years ago. And he's a pretty nice guy and he goes around promoting spring and stuff. And of course the last one is Leonard, he's from Zendesk and I met him in San Francisco last year. All of them have been very good inspiration models and it's the reason why I've been so passionate about computers and computer software so far. And you might be thinking, wow, what's all this got to do with the talk even, right? I'm here for a talk, not for you to promote about yourself. Anyway, let me talk about the talk itself. And of course with every talk people would like to begin it with some grand inspirational speech about, oh, how top companies has no drivers and things like that. And that's pretty lame and I don't want to talk about that. Let me talk about something else more interesting. Let's talk about the top numbers in the world. The first one is the number of JavaScript dependencies, top number. Nothing else is more than that, right? If you look in your node modules you'll see one million and one packages there. Second one is articles saying that PHP is dead. That's the second top number here, right? No doubt everyone's writing about how it's a dead language and why we are still here, we are really dead people, right? The last one, the most important number in this world, statistics made up on the spot, right? We know as people we always like to make up statistics on the spot and especially this one here is a fake one as well, just in case you didn't know. Okay, let's really get down to contents itself rather than all this. So I'm gonna first talk about what is RESTful? What is this term RESTful, right? And I'll be talking about the various schema standards surrounding this term RESTful and the patterns comparison between different patterns and different architectures. And finally a short demonstration about this wonderful JSON API that I've written in one hour, right? So what is RESTful? Okay, so this is actually supposed to show a emoji and I think the emoji support is broken and it shows a square there. What a sad thing. Right, so what is this RESTful? So a lot of people has been saying that, my company do RESTful APIs, you can go to this RESTful API and have your public key or whatever key, whatnot. Look at this wonderful RESTful API I've written here. Wow, it's so RESTful, it's blah, blah, blah. Wow, what is all this buzzword? I don't know, but I'm gonna say wow, I'm really amazed right now. Okay, so how many of you here actually understand what is RESTful? Any show of hands? Okay, so you'll probably be like, you'll probably be like me right now. Wow, this term sounds like very team term in what Singaporeans would call team term. And when someone says my API is RESTful, you open your mouth like this. I'm so awed by how you say your API is RESTful. And you say, wow, that's amazing. You are probably the best person in this world. Right, that's what we'll probably do, right? Let's be honest. And of course, there are definitions written by thought leaders. And one of the definition here in this book is RESTful Web Services. It's written by Richardson. I don't even know how to pronounce his first name. Okay, so Richardson's maturity model. In this, this is one of the content that I'll be focusing on. He talks about various levels of REST and how much REST can you get, right? So at the end of the day, we might get a good rest and be able to sleep well and get good rest. And of course, we all know good rest equals good productivity. When you wake up in the morning, you feel refreshed. You'll be like, wow, that was a really, really good rest, right? Most of us Singaporeans, we, we lack rest, right? We've got like negative two hours of rest every day. And we are like asleep deprived and stuff like that, right? Very bad. So once we finish this talk, once I finish this talk, you'll get a good rest at night later. Okay, so I want to ask people how much rest do you get? So have any one of you here written APIs before? Like, written any APIs, anything? One, two-hand, three, four, five, six, six-hands. Okay, that's, that's pretty okay. So in case you don't know what is API, so API is like an interface for developers to reach out to, right? So when you call an API, it returns something and then you use that something, do whatever you want. So let's say you call to a website, a e-commerce store, you call, you make an API call, and then it returns you certain staff that are available. And it generally can be written in two formats. One would be in JSON format, the other would be in XML format. So people here heard of JSON format? Everyone, all right, okay, so that, that, so now you probably understand what is APIs, right? So get whatever you want, you call it, you retrieve something, and that's it. That's really it. And when it comes to RESTful APIs, it's a little bit different. There are different types of APIs out there as well. You can do socket APIs which are stateful. You've probably heard of the term web sockets before. And like it can do streaming, and that is stateful. That means when you initiate a connection, there's a connection in between, right? So there's a state there. And when you do RESTful, it's usually stateless. And of course, you need to get it to be stateless, right? So when you initiate a request, there's no, the connection doesn't leave for long, right? So it replies you and then it ends. The connection is there. So it's stateless. Okay, so there are four levels of REST you can get. And when we reach the ultimate level of REST, we get what we call the glory of REST. And on level zero, we call swarm of pox, right? Imagine sleeping on the chair. That's how much REST you're going to get. So swarm of pox means that, oh, it uses HTTP technology. And that's it. So if your API is actually using HTTP technology, it's on the level zero, right? So wow, congratulations, you have created a level zero REST API. And second level, first, second level will be resources. So you'll be sleeping on this. I think people use this in the hospital to transport dead people and stuff like that. So you'll be sleeping next to dead people and probably, okay, resources. So what are these resources? What do you mean by resources? So when we talk about resources, it could be money, right? And we all like money and stuff like that. And but when we talk about resources, it could be other things too, like users. So for example, users slash one, right? When we call to a URL, it could be users slash one. Then we get the user with an ID of one, probably something like that. And it could be true, different methods. It could be a get, post, delete, whatever or not. We don't care about that first because that's only on the first level. We don't care about the HTTP verbs yet. So if you call towards a slash users using a post, it might just return you a list of users and that's it. So that's on the first level one of rest. On to the next level, we got HTTP verbs. This is where you actually get a proper bit that looks like it's full of fleas inside it. It's infested with fleas and you're going to get bitbuck bites at night and you wouldn't get that much rest either. So HTTP verbs introduces get, post, delete, put, whatever not. And this means when you do a get request to a slash users, it should not modify anything. It should just return you a set of data of the list of users. That's it, right? And when you do a post to slash users, it should create a user in the database. And in most cases, I've seen people writing APIs up to this level, right? A lot of companies actually reach until level two at least, where they still get bitbuck and stuff. So they've not reached the glory of rest yet. So actually, this is actually a term used. We call it the glory of rest, okay? And on the glory of less, we have hypermedia controls, which is what people call it, H-T-O-A-S, right? It sounds like a terrible term to describe things and people can't really pronounce it here. Neither can I pronounce it. So hypermedia control, wow, this term is so cheap. I've never heard before, right? I'm so amazed right now, wow. Okay, so hypermedia controls, like what? If you Google or DuckDuckGo, H-T-O-A-S, or you want to use Bing instead, because it's Microsoft Office, then people will start talking about, oh, it simply means that data should link from one point to another point. And let's say you go to users, you should be able to go to user slash two, user slash three, and then you're like, what is he talking about? Why can't my level one is really reaching that? You can really do slash one and things like that, right? Okay, I'll probably give you a more later on, definition later on, and you'll be surprised how simple it is, because simplicity is what we should be doing anyway. There are various schemers which we can use to achieve H-T-O-A-S. The first one would be HALE, they just call it H-A-L, and it's called Hypertext Application Language. It's used by WordPress. Okay, so if you do WordPress, if you communicate with WordPress APIs, it actually returns you data in a HALE format. And we've got another standard called JSON link data, or simply for short JSON LD. And it's another standard, oh God. Okay, here's the last one. It's called JSON API. Wow, we've got three standards. Why not create a fourth standard and then make things standardized, right? Okay, that's a very bad idea. Okay, so we've got three standards and they all have their pros and cons, and they are generally almost the same. They just want to create data linkages between one resource to another resource. So there's always phrases like resources. So resource connect from one resource to another resource. So you can jump from one resource to another resource. And how do you jump from one resource to another resource through the web? You just embed a link down there, right? That's so simple. So when you return the resource, it must have URLs there and that's it. Okay, so let me show a very simple JSON API create. So let's focus on the first part here. It says post to photos, okay? And then, so when we do a post to the photos, we are actually doing a create. And then the content type here is applicationvnd.api plus JSON. This is the, you must always have this content type for JSON API or else it will reject because it's not acceptable content type. Okay, it is the same as JSON, I suppose, but you must specify the content type to be in this way. And of course, when the response come back, you'll say accept, application, blah, blah, blah. And this is the content to require to do a create. So instead of doing what we do a post username and password, usually when we wanna create account, it's just a post username and password and that's it. So in JSON API standard, we do a data, then within the data object itself, we have type and this is a photos, so it's a type photos. Then within the attributes itself is finally where we would typically put in the username or password. So the attributes of the photo could be title and source. And then we have, and in our databases itself, where if you are doing like, let's say MySQL and not no SQL, like relational databases, right? If you are doing relational databases, there will be relationships connecting from one model to another or one resource to another resource. And here you see that there's a relationship and then photographer. So there's the, in the photos itself, it has a relationship with the photographer and with data type people ID, the photographer's ID. So this is what we send, right? This is not what we receive. So this is the type of data we need to send. Later on when we show the demo, it'll be clearer to show like what response we will be getting. Okay, so we've got so many schemers and whatnot. So let's talk briefly about the patterns in PHP in general or in computer science in general a little bit, right? It's kind of interesting to talk about patterns sometime and it's related to what I'm gonna talk about later on as well. So when we write JSON APIs like that and we are doing all these MVC whatever not, blah, blah, blah, we are usually doing a crud and a crud is create, read, update, delete which is a pretty boring stuff, right? So this is the typical pattern used in MVC and there's also another pattern called CQRS which I would talk about in a moment. And there are also various patterns within general application design. Linear versus parallel. And when we talk about linear patterns it could be synchronous and asynchronous too. It could be when we do parallel it could be synchronous and asynchronous too and that brings me to the third one, synchronous versus asynchronous, right? So why are you talking about all these patterns and what is this CQRS thing that you are talking about? What the hell is this CQRS whatever not? So it's common query responsibility segregation and it's a pattern that is similar to crud, right? It's both crud and CQRS are patterns and they both can be mixed, right? And I've not seen any people try to mix crud and CQRS yet and CQRS by design is a pen only. So what I mean by a pen only is that when you write a form of data the data appends forward and you add on more data. So you all heard of Bitcoin before is like blockchain stuff and things like that. So the term for that is called immutable and you append data forward nonstop to just keep appending data. And of course when we talk about immutability it's part of the functional paradigm too. And CQRS is a very rare pattern. If you ask around people beside you as well you ask them what is CQRS they would know. If you talk to them about crud they will say, oh yeah crud create read update delete. And even I've talked to functional programmers as well in Singapore they've not heard of CQRS which is kind of like what because you are a functional programmer and you don't know what is CQRS, right? Anyway, you might be thinking, okay, okay, wait a minute you have talked about all these schemers you've talked about these patterns and things like that. Now I wanna know if the API I've written over the weekend is still considered RESTful and will I get enough REST at home later on? Well, my answer is not really an answer but it's a answer still. RESTful is subjective. And there's always this and it was I've talked about it late earlier on about the Richardson's maturity model it was coined by thought leaders, right? People always say there's this thought leader stuff, right? And generally we would, generally speaking and most of the time we would wanna follow what these thought leaders have said because they've already gone through significant amount of experience and they've really used the technology for quite some time so they really are familiar with what they are doing and usually and most likely they are correct but sometimes they could be wrong too. So the term RESTful is subjective. Although I can say, oh, you must have hypermedia or Haiti OS to be RESTful. Some people might disagree with me and say, oh, it's still RESTful. My API is still RESTful, you know, whatever not. And then you might be thinking, okay, so who should I be listening to? Well, you could listen to anyone and the decision is ultimately still lies with you, right? And that's when I wanna talk about the book that I'm coming out with. Well, it's called Real RESTful APIs to standardize all APIs and then just listen to this book, right? And it will be released in 2096 because there's too many standards out there and there's too many ways to do things and there's too many people saying, what is RESTful API? So I'm gonna standardize everything and then write it in the book, right? No, I'm not gonna do that because that's gonna come out in 2096. Okay, so but seriously, when we talk about all of this RESTful term and things like that, we really wanna talk about context and trade-offs. What works for you might not work for someone else. What works in your API right now and you think it's RESTful, it might not be RESTful to someone else and there's always trade-offs, right? Engineering is all about making trade-offs and when should you do this? Should you do this or should you do that? What are the benefits, what are the cons? You should be always weighing the benefits and cons and not say, oh wow, he talked about JSON API. I'm gonna do this right now. I'm gonna start implementing it everywhere on the company and then later on, within a day or so, you get fired and then you come to me and say, oh no, where did you got me fired? Oh no, you must compensate me. Right, so yeah, context and trade-offs are very important and this brings me to the next point which I wanna talk about, which is domains. So has anyone of you here heard of domain-driven design? Domain-driven design, one, two? Yeah, I keep sitting in certain patterns, always these two front guys down here raising up their hands and like, hmm, okay, so anyway, domains. All right, so what is this term domain? Anyone has an idea of domain? Okay, it's anyone? Domain, anyone can just shout the answer if you know what's a domain. Yeah. Okay, so there's that domain as well. There's that wet domain and whatnot as well. There's also a domain, but not really relevant to what I say, but kind of relevant in some ways. Okay, so domain is like, for example, a specific area that you wanna target. So it could be something like, oh, I wanna solve the next big thing problem. I wanna make a cat, a Uber for cats, right? So that's my domain. I wanna make it available to cats and stuff like that. Then that's kind of like your domain, right? The problem that you wanna solve. And when we do domains and things like that, we have the term called domain-driven design, which we wanna target the domain itself. And what's so good about domain-driven design itself is that we don't care about the structure you are creating first. So you don't care about RESTful, you don't care about Haiti OAS, you don't care about whatever not, you don't care about your framework itself, you don't care about MVC either. You specifically target the problem. You look at the problem, you look at the domain. What are you trying to solve here? How can we get there and things like that? And what's so good about it is that I've seen companies, they always say, oh, we are trying to solve this problem. And then I wanna do it through this MVC framework called whatever not, KPHP or Laravel or whatever not, right? And we've got these models here, we've got this controller here, we've got these views here, but how do I get to solve my problem, right? So how do I structure it that way? So people will say, how do I structure my application to this thing, right? Which is kind of a big problem, you see. People ask, how should I structure my application? It should, the answer, the question you should be asking is, how do I solve the problem and how do I do it? Not how do I structure things, right? Because when you create structures, you're gonna get further away from solving the problems and then eventually you'll be far away from the problems and never solving your problems and having a useless piece of structure down there. Left alone, dying, crying and nobody really cares and then you move on to the next big project you have. Okay, we've talked about all this domain-driven design thing and so how do I, it sounds so good, so how do I do it? Okay, so first you wanna look at a business problem, then we target the business processes, what are the business processes in between to target the domain itself? And finally, then we start solving the problem, right? So that's basically domain-driven design in a nutshell. It's very summarized and again it's, okay, this is the summary of one of the thought leaders said again, yeah. So people might say, oh yeah, domain-driven design is something else. So people have different opinions again and this is generally I have to be less targeted, I quoted someone from the thought leaders as well. So now the next thing you might be thinking, okay, whoever, you've talked about this schemers, you've talked about this patterns and you've even talked about domain-driven design but what has all of this got to do with the actual application I wanna do at all? What has it got to do with JSON API at all? All right, so well, what I want you to take away is that even if you don't understand my talk at all, like you find it really boring and dry and I wouldn't blame you for that because maybe I'm a bad speaker. Okay, but what I want the audience to understand is that when you hear about new technologies and you hear about, okay, JSON API isn't new, but okay, if you hear about new technologies such as microservices, okay, your head will start standing up and things like that and then you'll be thinking about, oh, I need to do this right now because it's in trend. All right, so what I wanna tell all of you is that monoliths can be good, right? Choose what you want. Ultimately, it's targeting the domain and solving the problem, right? If you build a application, a microservice application, but you have not solved your own problem, then you've achieved nothing. If you've built your application with JSON API, but you've not solved your problem, you've achieved nothing either but of course you still got to achieve. You have already achieved glory of rest but you still haven't solved the problem, but yeah. Okay, now I'm gonna do a demonstration of, so a demonstration of API, right? So it's a Fidget Spinner API that is with JSON API. Okay, so with regards to Fidget Spinner, you might be, okay, here's a context. So you know US and China here? Who here knows what is US and China? Nobody? Okay, one hand, one hand, two hand, three hand. Five people here know what is US and China. So I've got to explain what is US and China. So United States of America is a country with a lot of states within it. Then China is a country in the East side. Okay, so now you know what is US and China and they seem to hate each other all the time. The news report that they hate each other and here's the good thing. There's something that will unite people together. Fidget Spinner, they unite countries together. Look at this, US, they're so happy. Look at him, oh wow. Because they import tons of Fidget Spinner from China so they are really happy. Wow, that's the stuff, man. China is like, excellent. Wow, that's pretty racist actually. Okay, in all of this Fidget Spinner stuff, I hope that was funny enough or at least I found it funny. Okay, so here we have this giant application down here. Okay, did I zoom wrongly? Okay, I've zoomed currently. So can all of you see this here? Or do I need to zoom in further? Okay, so this is a Laravel application. You can see it's obviously Laravel because I just mentioned that it's a Laravel application. So who here uses Laravel or have at least heard of Laravel before? Heard of Laravel before? Okay, so Laravel is one of the MVC framework following a crud and whatever not. It's one of the more popular framework nowadays. Okay, so in all of that, I'm gonna show you really quickly about how this stuff works here. So I've got this JSON API down here which I can't seem to zoom in because it doesn't like me. Yeah, there's no way I can zoom in this. Wow, this is terrible. Control plus, okay. No, Control plus doesn't work here. Oh, okay, wow, it works now. Okay, so in this application, I'm gonna show you there are two main models here, two main actors, user and fidget spinner. So when you have a user, they have multiple fidget spinners. So it's a one to many relationship. Just saying for you to get some context first. So when we call towards the API endpoint here, we've got, so this is my API endpoint is the local host in port 8,000. So it's slash API slash version one. And then the resource, the resource is the users itself. And then when I send a get request, it gives me this data here. So data, and it has an array here. So it's an array of data. And within it, there's this type called users. So from here, we can see that it's actually quite relatively understandable. When you look at the data here, it's very presentable. And of course, when it's presentable and consistent, it means that you get good rest at night. So ID, obviously it's the IDs. So when we go into ID slash one, there should be something. And then when it was created at, it was created at this timing, updated at what timing, name of this person, email of this person. Then it also contains the relationships it has. So it has a relationship with the fidget spinners. It has a very, very, very close relationship that nobody can break at all. A binding, forever binding relationship with fidget spinners, because why not? So this guy here, he has, this guy here named LL, he has zero fidget spinners. This means he is very, very sad, right? Very, very sad. So let's create another user first. Okay, look at this formatting that I've done here. It's bad formatting. Oh my God, I'm really bad at formatting. Yeah, so I have to switch, I have to set the type to raw. And the haters here, as I mentioned before, the content type must be set to application vnd.api plus json. Then the body that I'm gonna send here. So who wants to volunteer their name here? Anyone wants to volunteer their name? Sorry? Nobody, why are you so shy? Anyone wants to volunteer their name for data collection? No, I'm just kidding. It's not data collection, right? I wouldn't need your email, so I need your name. Anyone? Yeah, you know. Simson. Simson, okay. Sounds legitimate, right? So password, so usually we will always want to create very strong password, like password one, two, three. Right, this is the password we usually key in. And email, it's gotta be some legitimate email at something, right? So like xxfidget spinner lover xx at Springfield.com. Okay, so we're gonna send a post to this place, right? And then it's gonna give us a response. So I've just sent it. Okay, let's see what happened. Oh, so the response that I got back was data type, users, id2, created app, blah, blah, blah, name, email. And he's created with zero fidget spinners. But you see here, there's a link here which I can click on, right? So this is the beauty of the glory of rest, right? So when I click on this and then I press the send, it gives me the read resource of this. Right, you can see here, it's exactly the same thing. Wow, it's beautiful, it's beautiful. Okay, and then, yeah, it specifically points to this user with an id of two. And then you'll be like, okay, Huiren, that's not amazing at all, right? That looks kind of boring, okay? I want something cooler. Okay, I'll get you something cooler. It's fidget spinners, fidget spinners are cool stuff. Okay, so how do I send a request here? It's pretty simple. So I want to make a post as well to this request endpoint here. So post, and then I have to type in my data. Oh God, I just set the header type first. Huh, what? Where did I set the header here? Oh, here. So you might have noticed another thing as well. For non-get and non-delete requests, according to the JSON API, if your request is a get and a delete, it doesn't require you to set the content type to application-vnd.api plus JSON. But if it's a post, a pull or whatever, something else, it would need you to set the content type to this or else you get an error. Let me show you the error first when I don't do that. Okay, so there's supposed to be an error here and then it's supposed to show some error saying that the content type is incorrect. But I'm using a package which is relatively new that I'm also contributing to right now. It's a JSON API package. It's not even done yet. So it's like inversion 0.9.1. And there are still lots of things that are not done. And of course, pull requests are accepted. So if you want to contribute to open source, then you should do it. All right, so let's see, body, roll, and then it'll be something similar to this. So I want to create data as well to the fidget spinner. Oh, am I pasting? So here I need to change this to fidget spinners. So you can see it's really, really easy to use this JSON API thingy, thingy, what not. And yeah, it's fantastic. Okay, let me type faster. Color, so what color do you guys like? Red, red. Yeah, and notice how I purposely use American English because obviously it's the more superior English, right? Well, who said that? I'm gonna bomb you. Okay, so we've got a bunch of data here. And let me just double check if it's correct. Oh, did I copy correctly? Yeah, it looks correct to me. So let's see if it works. Sorry? Oh yeah, no need an ID attribute. Yeah. Oh yeah, good catch, I didn't even see that because I'm better looking. So here it returns me a very descriptive error as well. Error 500, and there's a good reason to why the errors are written in such a beautiful manner, right? You can see it's very consistent. So when an error is written, there's an error, then inside, there might be multiple errors, for example, let's say validation is incorrect, username is incorrect, name is incorrect, email is incorrect, then it will show all the error and then with a whatever not name. Okay, and let me show a very quick look at what it looks like. So in the user schema itself, we write schema files and then we write validators to validate the schema, obviously. And so it's really simple for you to write JSON API. So for me, I use this package called the cloud creativity JSON API package. So it's essentially within itself it encapsulates several other packages as well. So there are transformers, there are hydrators, there are schemers, there are validators, and actually you can see it here. Yeah, so there are different kind of files within schema, right, and then here I built the relationship and whatnot. And then if you look at it quite upfront, it's actually a bit more things to do, right? It's not as simple as it looks like it should be. And there are very good reasons for that and mainly because it's that people don't really want it. Like in particular, there's not much strong motivation for people to write APIs in a Haiti OS manner, right? Even like things like local transactions, people aren't even doing that as well. And I would like people to move away from this mindset of it's too troublesome so we shouldn't do it. And of course there are always pros and cons, right? So the cons is that it is kind of a bit troublesome to write in such a manner. And we are trying to fix that as well. I'm trying to help the repo people as well contribute some code and you can help contribute too if you want and make things simpler for the package to use. Well, the pros is that when, let's say you write a public API, this is very important and it is essential that you need to achieve Haiti OS. Let's say you write a public API for people to talk to, right? What kind of API could you be writing? So let's say an API for lab pad, right? So if you wanna do padding, like an API that adds padding to your text and stuff, then it's public where people talk to, where strangers out there, they need to talk to this API. Haiti OS allows you to achieve consistency and readability and link data, right? So the link resources from one point to another point. And yeah, those are the pros of using JSON API itself. Okay, so final slide. So while the package is still under heavy development and you can check it out under cloud creativity slash level dash JSON dash API. It's one of the better packages that I found so far because the packages I've looked around, they are not that great. Yeah, so they only, typically they only supply a transformer and that's it, there's no validator. You have to do your own validation. You have to throw your own errors, which in this case, I didn't throw my own error at all. It was handled by the system. And that's just a lot of things to do. Whereas this Laravel JSON API package here helps cut down a lot of that already. And well, of course documentation is quite bad. So help to, even if you don't know code, you can help add some documentation too. So that's it for my talk. And if you all have any questions, you all can speak to me later, I guess, or yeah. Any questions for me, right? Yes, hi. What's your name? What's your name? Darren. Sorry? Darren. Darren, so Darren, what's your question? So what is the links, right? You provide links for the resources. This link should just go up to an endpoint and the concepts get. Do you also post, do you also give links the concepts post? Yeah, so that's a very good question. And you can do get, you can do post as well. So let's say you have a slash users slash one. You can do a get to that and then you retrieve the particular read data. And if let's say you want to modify the data, you can then do a post slash users slash one. It's just providing a link and you are not handling the link building either. The link building is already handled by the system. You're not transforming any data either. You're just providing the model, yeah, and that's it. Yeah. You managed to break that API pass, you attached to the jspy. Okay, so there are some issues to the JSON API package itself. So there's one, it's actually a bit complicated to explain what happened just now. So basically I didn't pass in the data which the schema accepts and then it just chose that error. It's a very useless error and you can see it's just 500 internal server errors. It's pretty useless. So what I do to debug this, yes, I have to debug. I can't even write test for this. Right, so to debug this, I turn off the error handler for the JSON API and then it throws out the entire, it just vomits out the entire error and then I look through the error again. Yeah. So if you have any other questions regarding JSON API or Laravel or PHP in general, feel free to just talk to me later. I'm not scary, although I make very morbid and unfunny jokes. Okay, thank you.