Laravel route difference between {id} vs {tag}

I am new in Laravel pardon me if question is silly. I have seen a doc where they used

For get request

Route::get("tags/{id}","TagsController@show");

For put request

Route::put("tags/{tag}","TagsController@update");

What is the difference and benefit between this ? I understood 1st one, confusion on put route.

There’s no real difference as it’s just a parameter name, but you’d need some way to differential parameters if you had more than one in a route, i.e. a nested resource controller:

<!-- language-all: lang-php -->

Route::get('articles/{article}/comments/{comment}', 'ArticleCommentController@show');

Obviously you couldn’t use just {id} for both the article and comment parameters. For this reason, it’s best to use the “slug” version of a model for a parameter name, even if there’s just one in your route:

Route::get('articles/{article}', 'ArticleController@show');

You can also use route model binding. If you add a type-hint to your controller action for the parameter name, Laravel will attempt to look up an instance of the given class with the primary key in the URL.

Given the route in the second code example, if you had a controller that looked like this…

class ArticleController extends Controller
{
    public function show(Article $article)
    {
        //
    }
}

…and you requested /articles/123, then Laravel would attempt to look for an Article instance with the primary key of 123.

Route model binding is great as it removes a lot of find / findOrFail method calls in your controller. In most instances, you can reduce your controller actions to be one-liners:

class ArticleController extends Controller
{
    public function show(Article $article)
    {
        return view('article.show', compact('article'));
    }
}

Generally there's no practical difference unless you define a custom binding for a route parameter. Typically these bindings are defined in RouteServiceProvider as shown in the example in the docs

public function boot()
{
    parent::boot();

    Route::model('tag', App\Tag::class);
}

When you bind tag this way then your controller action can use the variable via model resultion:

public function update(Tag $tag) { 
   // $tag is resolved based on the identifier passed in the url
}

Usually models are automatically bound so doing it manually doesn't really need to be done however you can customise resolution logic if you do it manually

Normal way

Route::get("tags/{id}","TagsController@show");

function($id) 
{
    $tag = Tag::find($id);
    dd($tag); // tag  
}

With route model bindings

Route::put("tags/{tag}","TagsController@update");

function(Tag $tag) // Tag model binding 
{
   dd($tag); // tags  
}

ref link https://laravel.com/docs/5.8/routing#implicit-binding

Check this out: Route model bindings

Use id, Laravel will get the id from route, and it will be the tag's id, it is integer.

function show($id) {
    $tag = Tag::find($id);
}

Use tag, Laravel automatically resolves Eloquent models defined in routes or controller actions whose type-hinted variable names match a route segment name.
In URL, your tag parameter is integer, however in your controller action $tag will be a model object:

function action(Tag $tag) {
    $tag->name;
}

So you don't need to get the $tag by eloquent in your controller action. You just need to specify it is From model Tag $tag
It will do it automatically.

It's just a convention. You can call it all you want. Usually, and {id} refers to the id in your table. A tag, or similarly, a slug, is a string value. A tag could be 'entertainment' for video categories, while 'my-trip-to-spain' is a slug for the description of a video.

You have to chose the words what you are comfortable with. The value will be used to find in your database what record is needed to show the correct request in the view. Likewise you can use video/view/{id}/{slug} or any combination thereof.

Just make sure your URLs don't get too long. Because search engines won't show your website nicely in search results if you do. Find the balance between the unambiguous (for your database) and logic (for your visitors).