7 days of WordPress plugins, themes & templates - for free!* Unlimited asset downloads! Start 7-Day Free Trial

Next lesson playing in 5 seconds

  • Overview
  • Transcript

3.2 Restful Routes

In this lesson we'll move on to wiring up our front-end with test data by making requests to the blueprint RESTful routes.

3.2 Restful Routes

Hi, folks. In this lesson, we're gonna continue looking at blueprints, this time focusing on the RESTful Routes. Unlike the blueprint shortcut routes that are designed to be used from the browsers address bar for convenience, the RESTful Routes are there for us to get data from our application programmatically. These routes are not restricted to using the GET HTTP method and instead can use any other HTTP methods. Typically we would use the same create, read, update, and destroy operations that are available. And these map to the same blueprint actions as the shortcut routes, but we can use them programmatically so that we can build a front-end of our app around the API, and get a feel for how we want the data to be formatted. So our example app is a dashboard. Some other application that we want to monitor sends telemetry data to our app, and the dashboard is used to view this data. So it will make calls to the back-end to fetch it. In the last lesson, we only added a single record to the model, so it might be worth using Postman to add some more. I've got a collection of requests saved in the format that Postman expects, so I'll make sure these are included with the source code for the app, and you can just import them into Postman and send a bunch of requests yourself. So I'm just gonna send a few. I've got an error response here, and the reason why is because the app isn't running at this point. So we need to go to the command line and just lift the app. And now we see the same message about our data that we saw before. So let's choose option two again this time. Each time we open our app, Sails will present us with that message, so let's just fix that quickly. So if we go to the config and then models file, down at the bottom of the file here you can see there's an option for migrate, and it's currently commented out. Let's just remove the comment and then we won't have to choose number two every time we lift the app. So now we can go back to Postman, and we should be able to issue some more requests. And let's just send in a bunch of different events. Great. So the front-end of our app is going to use Angular, Angular Chart, and Chart JS. I've got an updated version of the index.html page that we added to the app earlier in the course. And I've also got updated versions of the styles.scss, and app.js files. So let's drop these into the project now, quickly. The index.html just goes into the root of the assets folder, the app.js just goes straight into the js folder, and the styles.scss file goes into the styles folder. So let's just open these up in the editor and take a quick look. So in the app.js file, we have our angular module, which is called Dashboard. And that relies on Chart JS as a dependency. And we've got simple controller called Main. And inside here, we set some various properties. But most of all, we make an HTTP request, that's a get request. To event/find. And that is one of the RESTful roots. And that's the root that we're gonna use to get all of the data, in order for this page to display it. And most of the rest of this file is just centered around formatting the data in the format that the charts.js plugin expects it to be in. So open this up, and have a good look through, at some point if you wish. Let's take a look at the updated index page now. And mostly we've just got the markup that our app requires and any directives that are required by angular. And now, let's just have a quick look at the new styles file as well. And mostly this contains bourbon or neat mix-ins for creating the layout that we need. So let's go back to the browser now. And we can view our app. And as you can see, there are some lovely graphs that are displaying the data that I've just added using Postman. So, if we shut down Sails and the browser and then come back later on and lift the site and open the index page in the browser again, all of the data will still be there. By default, Sails stores any model data that we add using the shortcut or restful routes in a simple file-based database called Sailsdesk, and this resides in the .tmp folder. Let's just have a quick look. And it say, no SQL file based data base that stores its data in Jason. We can open that up and take a look at all of the data that we've got in there. And if we need to drop the database at any time, we can just delete this file, and if we want to store some new data, Sails will just recreate it for us. So in this lesson we looked at the blueprint RESTful routes, and saw how these trigger the same blueprint actions that the shortcut routes that we looked at in the last lesson do, but we saw that these requests differ from the shortcut routes, in that we're not limited to using the get verb. This time the request URLs for all routes are almost identical, and it's the HTTP method, which is used which determines which root is used. And ultimately, which blueprint action is triggered by the request. So get/event triggers the find action. Post/event triggers the create action. Put/event/ID triggers the update action and DELETE/event/id triggers the destroy action. Thanks for watching.

Back to the top