Learning Laravel 6 and VueJS for Javascript/NodeJS developer part 3 - Routing general basics

Let's talk a little bit about routing in general, in laravel and in vuejs.

There are different kinds of routing on the web.

Host-based routing

To visit this website, you probably entered dev.to. dev.to is the hostname that is easy for you to remember. The host is the actual server/computer behind this hostname. Usually, you would call dev.to a (web) domain. There are also subdomains. For example wev.dev.to, mail.dev.to or api.dev.to. The part until the first . is the subdomain of dev.to. mail.dev.to can be a completely different server in a completely different region in the world. So by now, you should understand host-based routing. It means that you go around the web by chaining the host.

This kind of routing is usually not done on an application level. It is something that generally used in the background.

Path-based routing

Now that we know what a domain is. We can talk about path-based routing. To see this article you see that the URL of that page is not just dev.to. It also has some extras after dev.to. It should look something like dev.to/lampewebdev/XXX. If you consider the full-path in your routing, then you look at the URL from the beginning. This means you take into account the dev.to and everything after. This is not very common. What you usually do is take a look at everything that comes after dev.to. In our case, this would be /lampewebdev/XXX. Of course api.dev.to/lampewebdev and dev.to/lampewebdev will probably not return the same response. One could be JSON, and the other one would be HTML. This kind of routing is also used in laravel and with vuejs router.

Header-based routing

Header-based routing can also be an everyday thing if you have one URL for the HTML and JSON resources. For example, you could set content-type header for every request to determine if you want the application to give you either JSON or HTML.

If you want to go one step further, you can also route based on your custom headers. This is an advanced topic and should only be done if you have an excellent reason for this.

Restful routes

Restful routing is a prevalent pattern in web development. You should understand the basics of it. It is a way of connecting HTTP verbs with to controller actions.

HTTP verbs (HTTP request methods)

Usually, you have to specify what you expect from the HTTP request. The idea behind is to tell the server if you want to get some resource like JSON or HTML from it, or maybe you want to create something, or you want to remove something from the database. This intent of modifying should be already visible in the HTTP verb. We will talk about the four essential for us.

• GET This is probably the most used one. A get request should only retrieve data. You are asking the server "hey can you show me what is at this specific URL". A Get request could look like this: GET /index.html. Let's say your typing dev.to Into the browser bar then actually what the browser does is to decode the URL. It changes it to https://dev.to:443/. Almost all web server is configured to redirect the / path to index.html. So what you are doing is making a GET request to /index.html. A full request could look like this:

GET /index.html HTTP/1.1
Host: www.dev.to
Accept: image/gif, image/jpeg, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
(blank line)

• POST This one is for sending data to the server. Usually, it is used with forms and similar functionality in web apps. Creating a new user or creating a blog post etc. This method is not Idempotent. Idempotent means that when you do an HTTP request several times, the server will have the same state. When we create a new blog post, the server will not have the same state. This is the most significant difference to PUT. PUT will update the username for example and calling this one with the same username several times will not change the server.

• PUT Is almost the same as POST but should not be used in forms and it is Idempotent. A good use case for PUT is when you create an app where you can order food or a ticket. Even if the end-user calls PUT several times,, you only want to get one ticket booked.

• DELETE This one does what it says. Calling the DELETE method is meant for removing the state from the server. This can be some database entry or just some state saved by the server. DELETE calls should also be Idempotent.

CRUD

CRUD stands for Create, Read, Update, Delete. With these four operations, you can do everything to modify the state of your web app. I mean, that's it. There is not much to say here.

REST (Representational state transfer)

REST is a vital part of every Laravel app and API. Every controller can have these state transfers, which is a fancy way of saying that we are modifying data at the server level.

NAME	PATH	HTTP VERB	DETAIL
Index	/post	GET	This could display all posts or some overview. Returns HTML
New	/post/new	GET	This one should show a form to create a new post. Returns HTML
Create	/post	POST	Creates a new post. This should return some success or error request.
Show	/post/:id	GET	This, for example, could be /post/1 and should return the first post. Returns HTML
Edit	/post/:id/edit	GET	Shows a form where you can edit the post. Returns HTML
Update	/post/:id	PUT	This is the actual update call and should return a success or error message.
Destroy	/post/:id	DELETE	Delete a specific post. Should return a success or error message

As you can see, some of the PATH's are the same, but the HTTP Verb changes. It is essential to understand these concepts. They are useful not only for Laravel but almost every web application that uses a standard API. This changes a little bit GraphQL, but we will talk about GraphQL at some other point of time.

In the next part, we will have a look at how these concepts are represented in laravel. So stayed tuned!