123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224 |
- <?php
- return [
- /*
- |--------------------------------------------------------------------------
- | Standards Tree
- |--------------------------------------------------------------------------
- |
- | Versioning an API with Dingo revolves around content negotiation and
- | custom MIME types. A custom type will belong to one of three
- | standards trees, the Vendor tree (vnd), the Personal tree
- | (prs), and the Unregistered tree (x).
- |
- | By default the Unregistered tree (x) is used, however, should you wish
- | to you can register your type with the IANA. For more details:
- | https://tools.ietf.org/html/rfc6838
- |
- */
- 'standardsTree' => env('API_STANDARDS_TREE', 'x'),
- /*
- |--------------------------------------------------------------------------
- | API Subtype
- |--------------------------------------------------------------------------
- |
- | Your subtype will follow the standards tree you use when used in the
- | "Accept" header to negotiate the content type and version.
- |
- | For example: Accept: application/x.SUBTYPE.v1+json
- |
- */
- 'subtype' => env('API_SUBTYPE', ''),
- /*
- |--------------------------------------------------------------------------
- | Default API Version
- |--------------------------------------------------------------------------
- |
- | This is the default version when strict mode is disabled and your API
- | is accessed via a web browser. It's also used as the default version
- | when generating your APIs documentation.
- |
- */
- 'version' => env('API_VERSION', 'v1'),
- /*
- |--------------------------------------------------------------------------
- | Default API Prefix
- |--------------------------------------------------------------------------
- |
- | A default prefix to use for your API routes so you don't have to
- | specify it for each group.
- |
- */
- 'prefix' => env('API_PREFIX', 'api'),
- /*
- |--------------------------------------------------------------------------
- | Default API Domain
- |--------------------------------------------------------------------------
- |
- | A default domain to use for your API routes so you don't have to
- | specify it for each group.
- |
- */
- 'domain' => env('API_DOMAIN', null),
- /*
- |--------------------------------------------------------------------------
- | Name
- |--------------------------------------------------------------------------
- |
- | When documenting your API using the API Blueprint syntax you can
- | configure a default name to avoid having to manually specify
- | one when using the command.
- |
- */
- 'name' => env('API_NAME', null),
- /*
- |--------------------------------------------------------------------------
- | Conditional Requests
- |--------------------------------------------------------------------------
- |
- | Globally enable conditional requests so that an ETag header is added to
- | any successful response. Subsequent requests will perform a check and
- | will return a 304 Not Modified. This can also be enabled or disabled
- | on certain groups or routes.
- |
- */
- 'conditionalRequest' => env('API_CONDITIONAL_REQUEST', true),
- /*
- |--------------------------------------------------------------------------
- | Strict Mode
- |--------------------------------------------------------------------------
- |
- | Enabling strict mode will require clients to send a valid Accept header
- | with every request. This also voids the default API version, meaning
- | your API will not be browsable via a web browser.
- |
- */
- 'strict' => env('API_STRICT', false),
- /*
- |--------------------------------------------------------------------------
- | Debug Mode
- |--------------------------------------------------------------------------
- |
- | Enabling debug mode will result in error responses caused by thrown
- | exceptions to have a "debug" key that will be populated with
- | more detailed information on the exception.
- |
- */
- 'debug' => env('API_DEBUG', false),
- /*
- |--------------------------------------------------------------------------
- | Generic Error Format
- |--------------------------------------------------------------------------
- |
- | When some HTTP exceptions are not caught and dealt with the API will
- | generate a generic error response in the format provided. Any
- | keys that aren't replaced with corresponding values will be
- | removed from the final response.
- |
- */
- 'errorFormat' => [
- 'message' => ':message',
- 'errors' => ':errors',
- 'code' => ':code',
- 'status_code' => ':status_code',
- 'debug' => ':debug',
- ],
- /*
- |--------------------------------------------------------------------------
- | API Middleware
- |--------------------------------------------------------------------------
- |
- | Middleware that will be applied globally to all API requests.
- |
- */
- 'middleware' => [
- ],
- /*
- |--------------------------------------------------------------------------
- | Authentication Providers
- |--------------------------------------------------------------------------
- |
- | The authentication providers that should be used when attempting to
- | authenticate an incoming API request.
- |
- */
- 'auth' => [
- ],
- /*
- |--------------------------------------------------------------------------
- | Throttling / Rate Limiting
- |--------------------------------------------------------------------------
- |
- | Consumers of your API can be limited to the amount of requests they can
- | make. You can create your own throttles or simply change the default
- | throttles.
- |
- */
- 'throttling' => [
- ],
- /*
- |--------------------------------------------------------------------------
- | Response Transformer
- |--------------------------------------------------------------------------
- |
- | Responses can be transformed so that they are easier to format. By
- | default a Fractal transformer will be used to transform any
- | responses prior to formatting. You can easily replace
- | this with your own transformer.
- |
- */
- 'transformer' => env('API_TRANSFORMER', Dingo\Api\Transformer\Adapter\Fractal::class),
- /*
- |--------------------------------------------------------------------------
- | Response Formats
- |--------------------------------------------------------------------------
- |
- | Responses can be returned in multiple formats by registering different
- | response formatters. You can also customize an existing response
- | formatter.
- |
- */
- 'defaultFormat' => env('API_DEFAULT_FORMAT', 'json'),
- 'formats' => [
- 'json' => Dingo\Api\Http\Response\Format\Json::class,
- ],
- ];
|