--- layout: default permalink: /creating-an-adapter/ title: Creating an adapter --- # Creating an adapter If you want to address a file system, and there's no adapter available, you'll need to create your own. ## What is an adapter An adapter can be seen as a plug - it bridges the gap between initially incompatible API's. The job of the adapter is to translate requests into calls the file system understands and re-format responses to comply with the interface of the generic file system. An adapter should __NEVER__ be used directly. It should __ONLY__ be used to create a `League\Flysystem\FilesystemInterface` implementation instance. ## The main interface to implement An adapter is required to be an implementation of `League\Flysystem\AdapterInterface`. This interface dictates all the methods that need to be implemented. The interface of an adapter is similar to the `League\Flysystem\FilesystemInterface`, the method names are the same, but the response is often different. Responses from adapters are often arrays containing the requested value. This is done because many calls to file systems return more values than initially requested by the client. In order to be able to optimize file system handling, all metadata is returned. For instance, when a `listContents` call not only returns the paths, but also timestamps or other related metadata, this information is not lost. This information is returned through metadata, allowing caching decorators to pick it up, and store for further use. ### Response values key | description | type ----------- | ------------------------ | ----------- type | `file` or `dir` | `string` path | path to the file or dir | `string` contents | file contents | `string` stream | file contents | `resource` visibility | `public` or `private` | `string` timestamp | modified time | `integer` ## Sharing the wealth Have you created an adapter? Be sure to let us know! Either create an issue on the GitHub repository, or send a PR adding a link to the README. Contributions are always very welcome.