Download the PHP package alvinone/idoc without Composer
On this page you can find all versions of the php package alvinone/idoc. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download alvinone/idoc
More information about alvinone/idoc
Files in alvinone/idoc
Package idoc
Short Description Generate beautiful API documentation from your Laravel application
License MIT
Homepage http://github.com/ovac/idoc
Informations about the package idoc
Laravel IDoc - The API Documentation Generator
Automatically generate an interactive API documentation from your existing Laravel routes. Take a look at the example documentation. Inspired by Laravel Api Documentation Generator
Introduction.
Laravel IDoc generator (interactive documentation generator) is a seamless and complete plugin for generating API documentation from your Laravel's codebase. It is inspired by the laravel-apidoc-generator, ReDoc and the Open API initiative from Swagger. IDoc has been built with extendability so that it can easily adapt with your use case.
Features
- Extremely easy deployment
- Server Side Rendering ready
- The widest OpenAPI v2.0 features support
{.inline} - OpenAPI 3.0 support
- Neat interactive documentation for nested objects
{.inline} - Automatic code sample support
{.inline} - Responsive three-panel design with menu/scrolling synchronization
- Integrate API Introduction into side menu.
- High-level grouping in side-menu.
- Branding/customizations.
Installation
Note: PHP 7 and Laravel 5.5 or higher are the minimum dependencies.
Laravel
Publish the config file by running:
This will create an idoc.php
file in your config
folder.
Lumen
-
Register the service provider in your
bootstrap/app.php
: - Copy the config file from
vendor/ovac/idoc/config/idoc.php
to your project asconfig/idoc.php
. Then add to yourbootstrap/app.php
:
Usage
Configuration
Before you can generate your documentation, you'll need to configure a few things in your config/idoc.php
.
path
This will be used to register the necessary routes for the package.
-
logo
You can specify your custom logo to be used on the generated documentation. A relative or absolute url to the logo image. -
title
Here, you can specify the title to place on the documentation page. -
description
This will place a description on top of the documentation. -
version
Documentation version number. -
terms_of_service
This is the url to the terms and conditions for use your API. -
contact
Here you can configure contact information for support. -
license
A short and simple permissive license with conditions only requiring preservation of copyright and license notices -
output
This package can automatically generate an Open-API 3.0 specification file for your routes, along with the documentation. This is the file path where the generated documentation will be written to. Default: public/docshide_download_button
This section is where you can configure if you want a download button visible on the documentation.
-
router
The router to use when processing the route (can be Laravel or Dingo. Defaults to Laravel) -
servers
The servers array can be used to add multiple endpoints on the documentation so that the user can switch between endpoints. For example, This could be a test server and the live server. -
tag_groups
This array is used to separate groups that you have defined in little sections in the side menu. If you want to use it, make sure you add all groups because the unadded group will not be displayed. -
language-tabs
This is where you can set languages used to write request samples. Each item in array is used to generate a request template for a given language. New languages can be added and the existing ones modified after. You can add or edit new languages tabs by publishing the view files and editing them or adding custom view files to: -
security
This is where you specify authentication and authorization schemes, by default the HTTP authentication scheme using Bearer is setting but you can modify it, add others or even define it as null according to the requirements of your project. For more information, please visit Swagger Authentication. routes
This is where you specify what rules documentation should be generated for. You specify routes to be parsed by defining conditions that the routes should meet and rules that should be applied when generating documentation. These conditions and rules are specified in groups, allowing you to apply different rules to different routes.
For instance, suppose your configuration looks like this:
This means documentation will be generated for routes in all domains ('*' is a wildcard meaning 'any character') which match any of the patterns 'api/*' or 'v2-api/*', excluding the 'users.create' route and any routes whose names begin with admin.
, and including the 'users.index' route and any routes whose names begin with healthcheck.
. (The versions
key is ignored unless you are using Dingo router).
Also, in the generated documentation, these routes will have the header 'Authorization: Bearer: {token}' added to the example requests.
You can also separate routes into groups to apply different rules to them:
With the configuration above, routes on the v1.*
domain will have the Token
and Version
headers applied, while routes on the v2.*
domain will have the Authorization
and Api-Version
headers applied.
Note: the
include
andexclude
items are arrays of route names. THe * wildcard is supported. Note: If you're using DIngo router, theversions
parameter is required in each route group. This parameter does not support wildcards. Each version must be listed explicitly,
To generate your API documentation, use the idoc:generate
artisan command.
It will generate documentation using your specified configuration.
Documenting your API
This package uses these resources to generate the API documentation:
Grouping endpoints
This package uses the HTTP controller doc blocks to create a table of contents and show descriptions for your API methods.
Using @group
in a controller doc block creates a Group within the API documentation. All routes handled by that controller will be grouped under this group in the sidebar. The short description after the @group
should be unique to allow anchor tags to navigate to this section. A longer description can be included below. Custom formatting and <aside>
tags are also supported. (see the Documentarian docs)
Note: using
@group
is optional. Ungrouped routes will be placed in a "general" group.
Above each method within the controller you wish to include in your API documentation you should have a doc block. This should include a unique short description as the first entry. An optional second entry can be added with further information. Both descriptions will appear in the API documentation in a different format as shown below.
You can also specify an @group
on a single method to override the group defined at the controller level.
Specifying request parameters
To specify a list of valid parameters your API route accepts, use the @bodyParam
, @queryParam
and @pathParam
annotations.
- The
@bodyParam
annotation takes the name of the parameter, its type, an optional "required" label, and then its description. - The
@queryParam
annotation takes the name of the parameter, an optional "required" label, and then its description - The
@pathParam
annotation takes the name of the parameter, an optional "required" label, and then its description
They will be included in the generated documentation text and example requests.
Result:
Note: a random value will be used as the value of each parameter in the example requests. If you'd like to specify an example value, you can do so by adding Example: your-example
to the end of your description. For instance:
Note: You can also add the @bodyParam
annotations to a \Illuminate\Foundation\Http\FormRequest
subclass:
Indicating auth status
You can use the @authenticated
annotation on a method to indicate if the endpoint is authenticated. A field for authentication token will be made available and marked as required on the interractive documentation.
Providing an example response
You can provide an example response for a route. This will be displayed in the examples section. There are several ways of doing this.
@response
You can provide an example response for a route by using the @response
annotation with valid JSON:
Moreover, you can define multiple @response
tags as well as the HTTP status code related to a particular response (if no status code set, 200
will be returned):
@transformer, @transformerCollection, and @transformerModel
You can define the transformer that is used for the result of the route using the @transformer
tag (or @transformerCollection
if the route returns a list). The package will attempt to generate an instance of the model to be transformed using the following steps, stopping at the first successful one:
- Check if there is a
@transformerModel
tag to define the model being transformed. If there is none, use the class of the first parameter to the transformer'stransform()
method. - Get an instance of the model from the Eloquent model factory
- If the parameter is an Eloquent model, load the first from the database.
- Create an instance using
new
.
Finally, it will pass in the model to the transformer and display the result of that as the example response.
For example:
For the first route above, this package will generate a set of two users then pass it through the transformer. For the last two, it will generate a single user and then pass it through the transformer.
Note: for transformer support, you need to install the league/fractal package
@responseFile
For large response bodies, you may want to use a dump of an actual response. You can put this response in a file (as a JSON string) within your Laravel storage directory and link to it. For instance, we can put this response in a file named users.get.json
in storage/responses
:
Then in your controller, link to it by:
The package will parse this response and display in the examples for this route.
Similarly to @response
tag, you can provide multiple @responseFile
tags along with the HTTP status code of the response:
Generating responses automatically
If you don't specify an example response using any of the above means, this package will attempt to get a
response by making a request to the route (a "response call"). A few things to note about response calls:
- They are done within a database transaction and changes are rolled back afterwards.
- The configuration for response calls is located in the
config/idoc.php
. They are configured within the['apply']['response_calls']
section for each route group, allowing you to apply different settings for different sets of routes. - By default, response calls are only made for GET routes, but you can configure this. Set the
methods
key to an array of methods or '*' to mean all methods. Leave it as an empty array to turn off response calls for that route group. - Parameters in URLs (example:
/users/{user}
,/orders/{id?}
) will be replaced with '1' by default. You can configure this, however. Put the parameter names (including curly braces and question marks) as the keys and their replacements as the values in thebindings
key. - You can configure environment variables (this is useful so you can prevent external services like notifications from being triggered). By default the APP_ENV is set to 'documentation'. You can add more variables in the
env
key. - By default, the package will generate dummy values for your documented body and query parameters and send in the request. (If you specified example values using
@bodyParam
or@queryParam
, those will be used instead.) You can configure what headers and additional query and parameters should be sent when making the request (theheaders
,query
, andbody
keys respectively). - By default all middlewares are enabled, but you can set the
without_middleware
array to specify the middlewares you prefer to disable, you can even use ['*'] to disable all.
Open-API 3.0 spec file
The generator automatically creates an Open-API 3.0 spec file, which you can import to use within any external api application.
The default base URL added to the spec file will be that found in your Laravel config/app.php
file. This will likely be http://localhost
. If you wish to change this setting you can directly update the url or link this config value to your environment file to make it more flexible (as shown below):
If you are referring to the environment setting as shown above, then you should ensure that you have updated your .env
file to set the APP_URL value as appropriate. Otherwise the default value (http://yourappdefault.app
) will be used in your spec file. Example environment value:
Further modification
The info file in the view folder can be further modified to add introductions and further documentation.
Credits
This software uses the following open source packages:
You may also like...
- Laravel Api Documentation Generator - A laravel api documentation generator.
License
MIT
All versions of idoc with dependencies
fakerphp/faker Version ^1.12
illuminate/routing Version 5.5.* || 5.6.* || 5.7.* || 5.8.* || ^6.0 || ^7.0 || ^8.0
illuminate/support Version 5.5.* || 5.6.* || 5.7.* || 5.8.* || ^6.0 || ^7.0 || ^8.0
illuminate/console Version 5.5.* || 5.6.* || 5.7.* || 5.8.* || ^6.0 || ^7.0 || ^8.0
mpociot/reflection-docblock Version ^1.0.1
ramsey/uuid Version ^3.8 || ^4.0