Supported annotations
PHP 8 attributes vs docblock tags
Scribe v4 introduces PHP 8 attributes that provide the same functionality as the old docblock tags. Here's a quick comparison of what they look like:
- Docblock
- Attributes
#[Endpoint("Healthcheck", "
Check that the service is up. If everything is okay, you'll get a 200 OK response.
Otherwise, the request will fail with a 400 error, and a response listing the failed services.
")]
#[Response(["status" => "down", "services" => ["database" => "up", "redis" => "down"]], status: 400, description: "Service is unhealthy")]
#[ResponseField("status", "The status of this API (`up` or `down`).")]
#[ResponseField("services", "Map of each downstream service and their status (`up` or `down`).")]
public function healthcheck() {
return [
'status' => 'up',
'services' => [
'database' => 'up',
'redis' => 'up',
],
];
});
/**
* Healthcheck
*
* Check that the service is up. If everything is okay, you'll get a 200 OK response.
*
* Otherwise, the request will fail with a 400 error, and a response listing the failed services.
*
* @response 400 scenario="Service is unhealthy" {"status": "down", "services": {"database": "up", "redis": "down"}}
* @responseField status The status of this API (`up` or `down`).
* @responseField services Map of each downstream service and their status (`up` or `down`).
*/
public function healthcheck() {
return [
'status' => 'up',
'services' => [
'database' => 'up',
'redis' => 'up',
],
];
});
Attributes have the following advantages over tags:
- They're less error-prone (for us). With docblocks, everything is a string, so we have to parse it, and try to guess your intentions. There's a lot that can go wrong there. With attributes, you give us the exact values you want.
- They're less error-prone (for you). Attributes are a language feature, so you have IDE help built in. For instance, typing in
#[Response(
will bring up the list of parameters, so you don't need to memorize the specific order or field names. - They're programmable. Since attributes are actual PHP code (with some limits), you can do more. For instance, you can have
#[ResponseFromApiResource(paginate: self::PAGINATION_CONFIG)]
. You can create your own attributes to avoid repeating the same things.
On the flip side, attributes:
- can be bulky. They especially don't look good for long text, such as descriptions.
- don't look good on inline (closure) routes.
// This isn't valid PHP
#[Authenticated]
Route::get('/endpoint', function () { ... });
// This works, but it's not very nice visually.
Route::get(
'/endpoint',
#[Authenticated]
function () { ...
});
The good news is that you can mix them!
That means you can write an endpoint like this:
/**
* Healthcheck
*
* Check that the service is up. If everything is okay, you'll get a 200 OK response.
*
* Otherwise, the request will fail with a 400 error, and a response listing the failed services.
*/
#[Response(["status" => "down", "services" => ["database" => "up", "redis" => "down"]], status: 400, description: "Service is unhealthy")]
#[ResponseField("status", "The status of this API (`up` or `down`).")]
#[ResponseField("services", "Map of each downstream service and their status (`up` or `down`).")]
public function healthcheck() {
return [
'status' => 'up',
'services' => [
'database' => 'up',
'redis' => 'up',
],
];
});
This way, the text part stays textual, while the structured part uses the defined attributes.
If you'd like to try attributes, we made a Rector rule to automatically convert your tags to attributes. It will convert parameter tags to attributes, but leave text like endpoint titles and descriptions untouched.
Format
Annotations in docblocks typically consist of a tag (@-something
) followed by text in a certain format. Some important details: Attributes are written like a regular PHP function call, and you can use named parameters to make the code clearer.
Some things to note about tags:
-
The
@hideFromAPIDocumentation
,@authenticated
and@unauthenticated
tags are the only boolean tags; they don't take any text after them. -
In the "Format" sections below,
?
indicates an optional value. -
Tags typically default
required
tofalse
-
Most annotations are written in a "natural" format,
@tag value1 value2
, where Scribe figures out what value1 and value2 represent, based on the order. However, some tags also support fields (@tag key1=value1 value2
or@tag value2 key1=value1
).Tag fields don't have to follow a specific order; they can be at the start or end of the tag (but they generally cannot be in the middle). Tag attribute values which consist of multiple words should use quotes (eg
@tag key1="this is value1" value2
).
Some things to note about attributes:
- They all live under the
Knuckles\Scribe\Attributes
namespace. So you can either write#[Knuckles\Scribe\Attributes\Header]
, or write#[Header]
and have an import statement (use Knuckles\Scribe\Attributes\Header
). - Since they're regular PHP, you can easily find out the arguments with your IDE, like you would for a normal function call. We won't list all the arguments here.
- Attributes typically default
required
totrue
Here's a list of all the docblock annotations Scribe supports.
Metadata annotations
All metadata annotations can be used on the method or class docblock. Using them on the class will make them apply to all endpoints in that class.
Tag | Description | Format |
---|---|---|
@hideFromAPIDocumentation | Excludes an endpoint from the docs | @hideFromAPIDocumentation |
@group | Adds an endpoint to a group | @group <groupName> Example: @group User management |
@authenticated | Indicates that an endpoint needs auth | @authenticated |
@unauthenticated | Opposite of @authenticated | @unauthenticated |
Request parameter annotations
@header
/ #[Header]
Describes a request header.
Format: @header <name> <example?>
Examples:
- Docblock
- Attributes
@header Api-Version
@header Content-Type application/xml
#[Header("X-Api-Version")]
#[Header("Content-Type", "application/xml")]
public function endpoint() {...}
@urlParam
/#[UrlParam]
Describes a URL parameter.
Tag format: @urlParam <name> <type?> required? <description?> Enum: <list of values?> Example: <example?>
Notes:
- If you don't supply a
type
,string
is assumed. - To specify allowed values for this parameter:
- for tags: write "Enum: ", followed by the list of values.
- for attributes: use the
enum
parameter with either a PHP 8.1 enum or an array of values.
- To prevent Scribe from including this parameter in example requests:
- end the description with
No-example
when using tags - pass
"No-example"
as theexample
parameter when using attributes
- end the description with
- You can also use this on Form Request classes.
Examples:
- Docblock
- Attributes
@urlParam id
@urlParam id int
@urlParam id int required
@urlParam id int required The user's ID.
@urlParam language The language. Enum: en, de, fr
@urlParam language The language. Enum: en, de, fr. Example: en
@urlParam id int required The user's ID. Example: 88683
@urlParam id int The user's ID. Example: 88683
@urlParam id int The user's ID. No-example
#[UrlParam("id")]
#[UrlParam("id", "int")]
#[UrlParam("id", "int")]
#[UrlParam("id", "int", "The user's ID.")]
#[UrlParam("id", "int", "The user's ID.", example: 88683)]
#[UrlParam("language", "The language.", enum: ["en", "de", "fr"])]
#[UrlParam("language", "The language.", enum: SupportedLanguage::class)]
#[UrlParam("language", "The language.", enum: SupportedLanguage::class, example: "en")]
#[UrlParam("id", "int", "The user's ID.", required: false, example: 88683)]
#[UrlParam("id", "int", "The user's ID.", required: false, example: "No-example")]
public function endpoint() {...}