Update 2017-04-07: note that coming in Laravel 5.5, intersect will be removed and only will behave similarly to what is described below. See this PR for more information.

Background

Many Laravel developers would be familiar with the helpful only method found on the request object, which allows you to specify keys to pluck from the request:

public function create()
{
    $post = Post::create(request()->only('title', 'slug', 'excerpt', 'body', 'published_at'));

    return redirect()->route('posts.show', $post->id);
}

Not only does this simplify your workflow, it works quite nicely when completely unguarding your models by setting protected $guarded = [];. How many times have you been in a situation where you've added a new field to your model and been met with a MassAssignmentException because you forgot to update the $fillable property?

For newcomers to Laravel, you might find this suggestion dangerous, but using only means you will only pass the desired input to your model irrespective of what was passed via the request itself. Explicit safety, right in your controllers. I prefer this practice personally, to the point I usually make it the default in my applications by declaring a base model and having my models extend from that.

<?php

namespace App;

use Illuminate\Database\Eloquent\Model as BaseModel;

class Model extends BaseModel
{
    protected $guarded = [];
}

Remember, if you're going to take this approach, never use request()->all() when passing data into your model's create or update methods!

Using intersect() to simplify partial updates

Adam Wathan tweeted about an approach he uncovered whilst helping somebody out when approaching partial model updates. Consider this approach in the following, fairly standard controller update method:

public function update(Post $post)
{
    if (request()->has('title')) {
        $post->title = request('title');
    }

    if (request()->has('slug')) {
        $post->slug = request('slug');
    }

    if (request()->has('excerpt')) {
        $post->excerpt = request('excerpt');
    }

    if (request()->has('body')) {
        $post->body = request('body');
    }

    if (request()->has('published_at')) {
        $post->published_at = request('published_at');
    }

    $post->save();

    return redirect()->route('posts.show', $post->id);
}

Instead of littering your controller method with multiple request()->has('field') checks, you can employ the request object's intersect method. The intersect method will return a new array containing only the keys that are present in both the specified list and the request itself.

Using intersect allows you to easily handle a PATCH request - one where you partially update a resource's data, rather than all of it as with a PUT - in a much more concise manner:

public function update(Post $post)
{
    $post->update(request()->intersect('title', 'slug', 'excerpt', 'body', 'published_at'));

    return redirect()->route('posts.show', $post->id);
}

Now, when you submit a PATCH request to the update route with only the fields that you are wanting to change, when the request reaches the controller, the intersect method will compare your request input against the array of accepted keys (title, slug, excerpt, body, published_at) and return an array containing values that exist in both the request and this list. In this example, that will be title and slug.

PATCH /posts/1
{
    "title": "This is the new post title",
    "slug": "this-is-the-new-post-title"
}

Differences between only() and intersect()

Whilst only() is a useful method, it will return any key that doesn't exist in the request input with a null value, which combined with your now unguarded model, could lead you into issues.

// PATCH /posts/1
request()->only(
    'title', // = 'title'
    'slug', // = 'slug'
    'excerpt', // = 'excerpt'
    'body', // = 'body'
    'published_at', // = null
    'non_existent' // not in request
);

// [
//     "title" => "title",
//     "slug" => "slug",
//     "excerpt" => "excerpt",
//     "body" => "body",
//     "published_at" => null,
//     "non_existent" => null,
// ]

Meanwhile, intersect() will only return non-empty values that are present in the request input and the list of keys passed into the method.

// PATCH /posts/1
request()->intersect(
    'title', // = 'title'
    'slug', // = 'slug'
    'excerpt', // = 'excerpt'
    'body', // = 'body'
    'published_at', // = null
    'non_existent' // not in request
);

// [
//     "title" => "title",
//     "slug" => "slug",
//     "excerpt" => "excerpt",
//     "body" => "body",
// ]

A caveat to using intersect()

If you want to preserve keys that are posted with empty values - for example, if you wanted to make the published_at value null - you'll currently (5.4.16 at the time of writing) have to consider a manual approach.

Something along the following lines will do the trick:

array_only(request()->all(), [
    'title', /* = 'title' */
    'body', /* = 'body */
    'non_existent',
    'published_at', /* = null */
]);

// [
//     "title" => "title",
//     "body" => "body",
//     "published_at" => null,
// ]

Using Laravel's macro functionality, we can define the following in the boot method of your AppServiceProvider, for example:

\Illuminate\Support\Facades\Request::macro('onlyIncludingEmpty', function ($keys) {
    return array_only($this->all(), $keys);
});

This will allow you to use the onlyIncludingEmpty method on the request object directly:

public function update(Post $post)
{
    $post->update(request()->onlyIncludingEmpty(['title', 'slug', 'excerpt', 'body', 'published_at']));

    return redirect()->route('posts.show', $post->id);
}

Conclusion

Whilst intersect is nothing new or particularly special in Laravel-land, it is a concise way of handling a fairly common approach to updating application data. It removes a lot of superfluous code and conditional statements by leveraging framework tools on top of native language functions.

Be mindful of the differences between only and intersect, and how intersect won't return keys that have empty values.