 Restful APIs for Meteor, and then we'll do a quick walkthrough tutorial. Does everybody know what Restful APIs are? Probably you all do. Introduction, funny you should say that. Introduction here. So what is Restful APIs? This is the standard Wikipedia stuff. It stands for representational. Basically, it's a simple way for interdependent systems to communicate with each other in a kind of HTTP protocol-ish type of way. So, you know, either system can be in all kinds of frameworks or languages and they can interact in a very nice and kind of easy to implement kind of way. So Restful applications, they use HTTP requests and they do your normal CRUD type actions. So you'll create, read, update, delete type actions. So system A could say to system B, I don't know who you are or what you do, but I want to delete one of these records from your database. And it can make a very simple HTTP Restful call and do that without having to know how the implementation is actually done on the other side. So why do I need one? So why would you need a Restful API? So these are some examples of some use cases here. You have a media server app and you want to build a native mobile app, so you could use a Restful API for that. You could expose your API for any other system to get into your data. Again, you could integrate with other frameworks or platforms without having to integrate a DDP client. And then again, there's things like some types of data apparently don't translate to well over DDP. So large chunks of binary data or files. And it also avoids some overhead with creating web sockets, maintaining web sockets. So how would you implement a Restful API in your media app? Has anyone actually done this in the past? Did you use any particular technique or package? The server side rendering in there. The basic responses from there. Iron routers, sort of server side routes? Did you do something similar or? Quite a package. So it's quite low-low stuff. So I started looking at this a couple of weeks ago for another project. And there's quite a well-known package called Restavus, which seems to be or was the de facto standard for implementing Restful APIs in a media app. And then there was some more lower-level stuff so you could just define server side routes using Iron Router or the Rest API package, which is on top of that. And it wasn't actually that complicated. Alternatively, you could use the Connect MPM package, which is kind of like a bit more lower level again. Stuff. But then as of last week, the 20th of April, there was actually a new library that came out, a new package from Sashko, part of the MDG core group. And he's basically, he put a hackpad together about wanting to create a super-simple way of exposing your whole Meteor application through a very simple, restful library. So he created a new package called SimpleColonRest, which really makes things very, very easy to add a restful interface to your server. And what we can do is do a quick demo of that. So I've actually got, I try to make this demo more interesting. So I've got some hardware here, which is a Spark core Wi-Fi enabled microcontroller. And I'm going to try to communicate with that from my Meteor app through the cloud. So I've hacked up the leaderboard example from Meteor, and called it ledaboard, LEDaboard. And so I can vote for these things. And if I make red the winner, that should light up like that. And now, if I make blue the winner, that will light up. Blue. So, I think that's not the end of it. So rather than Meteor that, I put it on media.com, and so you can actually go to ledaboard.media.com and vote and change the LEDs. Try that. You'll probably blow up my microcontroller because you're all doing that, but you can vote for your favourite. And it kind of nicely shows off the reactivity and everyone's client changing. But I'm sure it's going to have trouble keeping up. Blue is winning. Give me some reds. Get all red. So it's probably trying to catch up with all the messages. So this is where it kind of breaks down. So unfortunately, what happens is you're changing the client's side. You're going into the back end to the Meteor side. The Meteor side is then saying, I need to make a call through the Spark cloud infrastructure to this guy. And now that's probably what's flashing red now. It's probably saying, hey, what's going on? So many messages. It's trying to reconnect to the internet now. Oh, red. You see? Red. The winner. There we go. So I thought that was kind of interesting. So this actually does not actually demonstrate the rest of the interface for Meteor, by the way. I should just tell you that. But we are going to demonstrate it using this. So here's Postman. Has everyone used Postman before? Anyone? Postman is a really, really useful tool for testing out your API calls to any other kind of system. It's based on Chrome. You can set up your API call, your endpoint here. You can add parameters to your body of your call and stuff. So here I'm going to call. So what I've done on the server side of the Meteor app is I've exposed these functions. Switch off blue, switch on blue, switch off red, switch on red. So I can call this directly here. So I'm going to call this using the rest of the interface now. So switch off blue. So if I do that, this guy should error first. And then if he reconnects. OK, switch off blue. Let's try switch on blue. I was reconnecting again. Did somebody do something? No. Maybe that was me. Switch off red. Let's try that. OK. I've got a feeling it's still catching up with all those messages that came in before. OK. So let's switch off. Let's try switch on red. So I can switch on and off the LED using a restful call. Kind of fun, but useless. So how do we do that? So let's do an example of actually creating a very simple app with a restful interface. So this is the new package from MDG. Simple rest. It's in atmosphere. There's quite a lot of nice documentation down here. So you can actually check it out. And I think it's got some examples in here. But we'll do a quick example. Now if you go to the gist here, which we're going to use, the gist URL is bit.ly slash meteor sg dash rest. Yeah, it's that one here. So you've got that? Yeah. Then you should get to this page here. Anybody need to see that again? No? OK. So we'll just work through these steps here. So here, again at the top here, this is the leading board example with the LEDs. This is basically, we could have done this actually using our shell if we wanted to. We could have just done a curl from the command line here. Switch on blue if I've done that. That guy should go on again having. That's basically when it disconnects from the Wi-Fi and has to reconnect. That should go on. So you can do it through curl if you don't have postman. So let's start from here. Walkthrough of creating a new media app with RESTful API. OK. So let's start by creating the example app. So media create dash dash example to do's. OK. That's done. Let's just take a quick look at that. That's there. I run that guy up. You should be kind of familiar with this thing. OK. So we have our standard media to do's app. We can create new tasks. We can look through lists of things. We can sign in all the normal stuff. You can account. So this is our standard media to do's app, but it doesn't actually have any RESTful interface at the moment. So it's just a standard media reactive. So let's add a RESTful interface to this app. So let's go back to here. So the next thing we need to do is add a few packages. So if you copy this line down here, add simple REST. Simple REST, simple JSON, simple REST accounts password. Is that OK? And then we'll just edit one of the files. Start up your favorite text editor. And then in server publish.js, we're going to just change that method, the publish method at the bottom of the file and just to override it with this guy from the gist. Basically all this is doing is adding a customized URL for that route for the RESTful interface. So it's adding an endpoint here with publication to do's and an argument, colon zero, to make that accessible at that URL. Overwrite that. Save that. And then you have to add this part down here as well, this JSON route stuff. If you want to access your API from outside your app from any kind of random place. So you have to copy and paste that in. It's done. Then go back to curl. And now we can actually query what routes are in the app. You can see we've got some routes, API endpoints set up now for all our publications, all our methods. And this actually obeys all your security rules so it should only allow you to do stuff that you're allowed to do. It's a bit nicer to see in postman. List of routes. So you do localhosts, publications, API routes. So that's the same for all applications. If I do that now I can see all these guys. All these routes are now set up for calling. So it's super simple. It took me like five minutes to do that. So let's just try calling one of these guys. So let's say I want to get all the public lists from my to-dos app. So there should be something like public lists. And then I've got a list of my, I've got return, all the media principles, languages, favourite scientists. So you can see all this stuff over here. Or you can use postman. Let's try a different one. Okay, so that's that. Okay, so that's basically... No, did everyone get that working? Gave up, got bored? No? Yep. Okay, so this claim, the claim of wrestling has gone very, very low point. Currently there's two parts when you look at the rest of the app. The first thing is usually the guys who make up the page start with the wrestling defence words. This is how your wrestling defence is supposed to look. Please write your code according to me. So how would I do that in the media? That's one of the second things. It seems to emerge a standard for documenting the stuff. Swagger.io. Is there any chance to generate a Swagger file out of here? I did read some threads about... I mean, it's still quite new. It's less than a week old. So I think they're working on getting the documentation or some way of automating their documentation from the rest of the API out of this. I can't remember if it was the one that you mentioned or maybe there's another one. I think... It is basically a stinky, indecent textifier so there's nothing special about it. I think I do remember reading something about that. Someone else was asking about that. I'm sure it will come eventually. The other question I'll take in terms of defining your restful API first and what you need to actually call rather than just like, okay, here's everything. Again, I think you probably... I haven't played with it too much but I think you can probably somehow find a more tidier way to control what is actually exposed and not exposed and apparently this library will obey all your roles that you've got all your authentication, security stuff that you've already got in your media app will actually be followed by using this method as well. So you shouldn't be able to do things that you're not allowed to do using this. Interesting exercise like sitting down to write the reverse one. I think there is one sort of command line tool where people are actually saying you can define your application in some sort of file and then run a command and it will actually create the bare bones application based on what you're telling it to do. I can't remember what it was called. Is it a meeting? Not meet your kitchen, right? I'll try to get out for you. Okay, so that's kind of it. I'll try to get out for you. I'll try to get out for you. I'll try to get out for you. I'll try to get out for you. So that's kind of it on the API. Any other questions? Is authentication supported? Yeah, so with this package apparently it's also supported. I mean the REST form that means allowing only a certain client. So there's actually again I haven't played with this yet but there's an authentication here. So there's a way to actually login as well of HTTP and that's why we added this package to the REST accounts parcel and stuff. So yeah, take a look at that. REST of us? REST of us? Yeah, I think that was the first one. So I mean REST of us has been around for a while and it's I think the guy who wrote it or the woman Kamali she's actually been involved in the hackpad that Sashka was writing when he came up with this and it seemed like they're going to be working together so it looks like there's some stuff which REST of us might still be valid for. Again I have not really played with that so I'm not sure. I was trying to find out why would you use this and why would you use REST of us which use cases are best for each but it looks like they're working together and REST of us will actually may change as a result of this but it's still going to be around for some reason. REST of us so I actually do stuff that you might need to do so again sorry I don't know exactly why that package is REST of us if we already developed something REST of us in the same project I think you can so I think with the let me just check because The roles might clash Let me just go to check because I think well something in the hackpad about this The simpad that is Simplies and REST of us is more complicated You have the right model Yes we have the right model That's a bad thing No it's not a bad thing It's just more wider Yeah again I'm not sure I think I'll put a link to the hackpad in the notes so you can take a look at that but it seems like the author of the REST of us is still quite actively involved in this stuff as well so it doesn't look like For what I can see they're not going to deprecate REST of us so there's probably still a use case for it somewhere Okay Okay so before I finish there is a few If you're kind of I don't know how many people are kind of new to me to your book there's a lot more stuff out there resources for learning and like keeping in touch with what's going on developments I'll just put a small list together of things that I follow to stay in touch So there's a couple of mailing lists created at IO and this week in media is quite a nice one it's like just a weekly one-off and it summarises like the top five or ten like main changes happening There's a couple of blogs you might have probably come across those the first one is media hacks, the one that Aranoda runs Podcasts If next time you're on the treadmill something interesting to listen to Obviously there's an official meteor channel where they have the deaf shop talks which is kind of like the latest breaking stuff they normally announce and then of course there's some sort of forums to help Don't forget the media Singapore Facebook page because we've got like 300 members on meetup.com but we've only got like 70 people on the Facebook page so something's going wrong So like the Facebook page because that's where we often discuss stuff and also join the Slack chat because it's a bit quiet bit boring so yeah, join the chat that's it