[Dingo/API](🔗) is a popular open source project that provides us with a set of tools to help us easily and quickly build our own API.

This starter package provides a sane configuration for dingo/API with optional JWT support. Note that it's up to you to explore additional configuration options and functionalities provided by dingo/API on their [wiki](🔗) as only the basics have been pre-configured here.

# API Setup

The api prefix is configured to be `/api/`, this means all your endpoints will be preceded by `/api/`. This is defined in your `.env` file and effectively active in your `config/api.php`. Feel free to explore other options, like setting a subdomain instead of a prefix.

🚧

Debugging

You can enable debug mode on the API with the `API_DEBUG=true` entry in your `.env` file, in case you'd output the stacktrace of an error.

# API Versionning

The default version for the API is set to `v1`. This is very helpful if you'd like to support backward compatibility for some endpoints on your API. This default verison is applied in `app/Providers/RouteServiceProvider.php`, since most users start off with just 1 version so it was moved out of your way from the routes file. Feel free to remove it from there and add it manually to specific routes in your `routes.php`. You can also create a routes file per version. It's all up to you.

# Content Negotiation

You're probably wondering: how does the client ask for a specific version? This happens through content negotiation, which is the `Accept` header sent with every request. Here's the `Accept` header that you need to send to specify a `json` response format and version `v1`: `Accept: application/x.laravel.v1+json`

You can see these values in your `config/api.php`. Feel free to change them (and update them in your [Restangular configuration](🔗) ). Although this header is not required, it has been configured in your Restangular configuration by default. However, it is recommended that you enable Strict Mode on your `staging` & `production` environment using `API_STRICT=true` in your `.env` file. Strict mode would force the client to send the Accept header. Forcing the client to send the accept header will make sure that other potential users of your API (other developers maybe?) are using the correct version of your API so they won't be affected when you release a new version (say `v2)`.

So as a wrap up, content negotiation allows the client to request a specific version and a specific return type from the API.

📘



You don't have to enable strict mode locally, as it'll make testing a bit painful.