Merge branch 'release/3.3.0'

Author: lindyhopchris

1.0/getting-started/core-concepts.md

@@ -7,9 +7,9 @@
 Your Laravel application can have any number of JSON:API compliant
 APIs. We refer to each API as a **Server**.
 
-You may not use multiple servers: a simple application
-may only have one server. However, there are a number of use cases where
-you may decide to implement multiple servers. For example:
+You may opt to not use multiple servers: a simple application will
+typically only have one server. However, there are a number of use cases
+where you may decide to implement multiple servers. For example:
 
 - If you have a public-facing API, and a private API (e.g. only accessible
 by administrators).

2.0/getting-started/core-concepts.md

@@ -7,9 +7,9 @@
 Your Laravel application can have any number of JSON:API compliant
 APIs. We refer to each API as a **Server**.
 
-You may not use multiple servers: a simple application
-may only have one server. However, there are a number of use cases where
-you may decide to implement multiple servers. For example:
+You may opt to not use multiple servers: a simple application will
+typically only have one server. However, there are a number of use cases
+where you may decide to implement multiple servers. For example:
 
 - If you have a public-facing API, and a private API (e.g. only accessible
 by administrators).

3.0/getting-started/core-concepts.md

@@ -7,9 +7,9 @@
 Your Laravel application can have any number of JSON:API compliant
 APIs. We refer to each API as a **Server**.
 
-You may not use multiple servers: a simple application
-may only have one server. However, there are a number of use cases where
-you may decide to implement multiple servers. For example:
+You may opt to not use multiple servers: a simple application will
+typically only have one server. However, there are a number of use cases
+where you may decide to implement multiple servers. For example:
 
 - If you have a public-facing API, and a private API (e.g. only accessible
 by administrators).

3.0/routing/README.md

@@ -340,10 +340,20 @@ use the `middleware` method:
 $server->resource('posts')->middleware('my_middleware1', 'my_middleware2');
 ```
 
-:::tip
-If you want to add middleware to specific resource actions, you should
-use [Controller middleware.](https://laravel.com/docs/controllers#controller-middleware)
-:::
+Alternatively, you can specify middleware per resource action. To do that,
+provide an array to the `middleware()` method. Middleware that applies to
+every action should use the `"*"` key. Middleware for a specific action
+should be keyed by that action.
+
+For example:
+
+```php
+$server->resource('posts')->middleware([
+    '*' => 'my_middleware1', // applies to all actions
+    'show' => 'my_middleware2', // apples to just the "show" action
+    'store' => ['my_middleware3', 'my_middleware4'], // use arrays for multiple
+]);
+```
 
 ## Defining Relationships
 
@@ -449,6 +459,22 @@ The following example adds middleware to our `tags` relationship routes:
 $relationships->hasMany('tags')->middleware('my_middleware1', 'my_middleware2');
 ```
 
+Alternatively, you can specify middleware per relationship action. To do that,
+provide an array to the `middleware()` method. Middleware that applies to
+every relationship action should use the `"*"` key. Middleware for a specific
+action should be keyed by that action. Use our short-hands of `related`,
+`show`, `update`, `attach` and `detach` for the actions:
+
+For example:
+
+```php
+$relationships->hasMany('tags')->middleware([
+    '*' => 'my_middleware1', // applies to all actions
+    'show' => 'my_middleware2', // apples to just the "show" action
+    'update' => ['my_middleware3', 'my_middleware4'], // use arrays for multiple
+]);
+```
+
 ## Route Model Binding
 
 By default Laravel takes care of substituting parameter values for models using