A route in Laravel is essentially an endpoint specified by a URI that acts as a “pointer” to some piece of functionality offered by the application. More often than not, the route simply points to a method on the controller and also indicates which HTTP methods can use that URI. Route also does not always mean a controller method; it can simply pass the execution of the application to a specific Closure function or anonymous function.

Why use a route?

Routes are stored in files in the / routes folder inside the project root. By default, there are several different files corresponding to different “sides” of the application (“sides” come from the hexagonal architecture methodology). These include:

  • web.php Routes based on public browsers. These are the most common and this is what gets into the web browser. They go through the web middleware group and also contain csrf protections (which help defend against malicious attacks and form-based hacks) and usually contain some degree of “state” (by which I mean they use sessions)
  • api.php Routes that match the API group and therefore have API middleware enabled by default. These routes are stateless and have no session or cross-request memory (one request does not share data or memory with any other request – each is itself encapsulated).
  • console.php These routes correspond to the custom artisan commands you have created for your application.
  • channel.php Registers routes for broadcasting events

The key file to consider at this point is the browser, web.php. By default, one route is already defined, which you take when navigating to the web root of your application (the web directory is in the public directory). For the download application to work, we need three different routes:

  • / upload This will be the URI of the main page that displays our web form for uploading files.
  • / process This will be the place where the form, located in the / upload URI, submits its data submitted by the form (the “action” of the form)
  • / list This will list all files uploaded to the site

Note . The / list endpoint may not be needed if we want to put all the logic for displaying the upload form and the file list on the same page, but I’m keeping them separate for now to add some more stuff to the topic in hand.

// inside routes / web.php
Route :: get ('/ upload', 'UploadController @ upload') -> name ('upload');
Route :: get ('/ download,' UploadController @ download) -> name ('download');
Route :: post ('/ process', 'UploadController @ process') -> name ('process');
Route :: get ('/ list', 'UploadController @ list') -> name ('list');

For each desired route, we explicitly list it in the web.php routes file using one of the available HTTP specific request methods (get (), post (), put (), delete (), patch (), or options ()). For a breakdown of each one, check this . These methods determine which HTTP verbs are allowed to access a given route. If you need a route to be able to accept more than one HTTP verb (which might be the case if you are using a single page to display both the original data and post the submitted form data), you can use the Route :: any () method …

The second argument to Route :: get () and Route :: post () (and any other method associated with the HTTP verb on the Route facade) is the name of the specific controller and the method that is placed inside it. a controller that starts when the route endpoint is reached by an allowed HTTP request (GET, POST, PATCH, etc.). We use UploadController for all three routes and set them like this:

The last method that we call on each route is its name () function, which takes one string as an argument and is used to more or less “mark” a specific route by simply remembering the name (in our cases, load, process and list) … I realize it’s not such a good feature to give each route its own name when the url is exactly the same, but it’s really handy when you have a specific route like / users / profile / dashboard / config, which was would be easier to remember as profile-admin or user-config.

Note on the facades:

  • Facades provide a “static” interface for the classes that are available in the application’s service container. “
  • They provide a concise, memorable syntax that allows you to use Laravel functions without having to remember long class names that need to be entered or configured manually.

In the above route definitions, we are using the Route facade instead of manually instantiating a new Illuminate / Routing / Router object and calling the appropriate methods on that object. It’s just a shortcut that saves typing. Facades are heavily used throughout the Laravel framework – you can and should become more familiar with them. 

Leave a Reply

Your email address will not be published. Required fields are marked *

Leave a Reply

Your email address will not be published. Required fields are marked *