Let's talk a little bit about routing in general, in laravel and in vuejs.
There are different kinds of routing on the web.
To visit this website, you probably entered
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
api.dev.to. The part until the first
. is the subdomain of
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.
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
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 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 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.
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.toInto 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
/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)
POSTThis 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
Idempotentmeans 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
PUTwill update the username for example and calling this one with the same
usernameseveral times will not change the server.
PUTIs almost the same as
POSTbut should not be used in forms and it is
Idempotent. A good use case for
PUTis when you create an app where you can order food or a ticket. Even if the end-user calls
PUTseveral times,, you only want to get one ticket booked.
DELETEThis one does what it says. Calling the
DELETEmethod is meant for removing the state from the server. This can be some database entry or just some state saved by the server.
DELETEcalls should also be
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 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.
|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
|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!