anchor.diff:  
   **All rules is applied in a order they were defined.**
   
  -### Bind Validator Plugin [POST /apis/{api_id}/plugins]
  -
  -+ Parameters
  -    + api_id: 1 (string) - API ID.
  -
  -+ Request (application/json)
  -    + Attributes (Plugin_Validator)
  -      + name: validator (string, required)
  -
  -+ Response 201 (application/json)
  -    + Attributes (Response_OK)
  -        + meta (Response__Meta)
  -            + code: 201 (number)
  -        + data (Plugin_Validator)
  -          + name: validator (string)
  -
  -### Change Validator Config [PUT]
  -
  -+ Parameters
  -    + api_id: 1 (string) - API ID.
  -
  -+ Request (application/json)
  -    + Attributes (Plugin_Validator)
  -
  -+ Response 200 (application/json)
  -    + Attributes (Response_OK)
  -        + data (Plugin_Validator)
  -          + name: validator (string)
  +### Bind or Update Validator Plugin [PUT]
  +
  ++ Parameters
  +    + api_id: 1 (string, required) - API ID.
  +
  ++ Request (application/json)
  +    + Attributes
  +        + validator (`Plugin_Validator__Request`)
  +
  ++ Response 200 (application/json)
  +    + Attributes (Response_OK)
  +        + data (`Plugin_Validator__Response`)
  +
  ++ Response 201 (application/json)
  +    + Attributes (Response_OK)
  +        + meta (Response__Meta)
  +            + code: 201 (number)
  +        + data (`Plugin_Validator__Response`)
   
   ## Idempotency [/apis/{api_id}/plugins/idempotency]
   
  -Gateway supports idempotency for safely retrying requests without accidentally performing the same operation twice.
  -
  -To perform an idempotent request, attach a unique key to any POST request made to the API via the `X-Idempotency-Key: <key>` header.
  -
  -Gateway always send back the same response for requests made with the same key. However, you cannot use the same key with different request parameters. <!-- The keys expire after 24 hours. -->
  -
  -### Bind Idempotency Plugin [POST /apis/{api_id}/plugins]
  -
  -+ Parameters
  -    + api_id: 1 (string) - API ID.
  -
  -+ Request (application/json)
  -    + Attributes (Plugin_Idempotency)
  -      + name: idempotency (string, required)
  -
  -+ Response 201 (application/json)
  -    + Attributes (Response_OK)
  -        + meta (Response__Meta)
  -            + code: 201 (number)
  -        + data (Plugin_Idempotency)
  -          + name: idempotency (string)
  -
  -### Change Idempotency Config [PUT]
  -
  -+ Parameters
  -    + api_id: 1 (string) - API ID.
  -
  -+ Request (application/json)
  -    + Attributes (Plugin_Idempotency)
  -
  -+ Response 200 (application/json)
  -    + Attributes (Response_OK)
  -        + data (Plugin_Idempotency)
  -          + name: idempotency (string)
  +Gateway supports idempotency for safely retrying POST requests without accidentally duplicating entity.
  +
  +To perform an idempotent request, attach a unique key to any POST request made to the API via the `X-Idempotency-Key: <idempotency_key>` header.
  +
  +Gateway always send back the same response for requests made with the same key. However, you cannot use the same key with different request parameters.
  +
  +### Bind or Update Idempotency Plugin [PUT]
  +
  ++ Parameters
  +    + api_id: 1 (string, required) - API ID.
  +
  ++ Request (application/json)
  +    + Attributes
  +        + idempotency (`Plugin_Idempotency__Request`)
  +
  ++ Response 200 (application/json)
  +    + Attributes (Response_OK)
  +        + data (`Plugin_Idempotency__Response`)
  +
  ++ Response 201 (application/json)
  +    + Attributes (Response_OK)
  +        + meta (Response__Meta)
  +            + code: 201 (number)
  +        + data (`Plugin_Idempotency__Response`)
   
   ## IP Restriction [/apis/{api_id}/plugins/ip_restriction]
   
  
positive.code: 
  For perfomance issues Annon has build-in cache manager, it will load data from DB only once, all futher work will be based on this cached data.
  
  Whenever a single node receives request that cache has been changed, it's responsible to notify all other nodes in cluster about change, and they should reload configurations from DB.
  
  Whenever new node joins cluster, all other nodes should drop their cache, to resolve consistency issues.
  
  This feature is done via [skycluster](https://github.com/Nebo15/skycluster) package. All gateway nodes is connected via Erlang distribution protocol. It support different discovery strategies: kubernetes, gossip and epmd.
  
  ### Requests Idempotency
  
  Annon guarantess that replayed requests with same `X-Idempotency-Key: <key>` and same request will get permanent response. This is useful in a financial application, where you need good protection from duplicate user actions.
  
  ### Request ID's
  
  When receiving request gateway will generate unique `request_id`. It is used to log request and this request is sent to all upstream, so whole back-ends that is affected by a request will create logs with same request id's.
  
  Optionally, you can send `X-Request-ID` header with your own request id, but you need to make sure that its length not less than 20 characters. Also, if should be unique, or you will receive error response.
  
  ## Default Plugins
  
  ### Request Logger
  
  By-default, gateway will log all requests and responses by their unique request-id's. You can view find them later in [Requests](#reference/requests/collection/get-all-requests).
  
  Also, idempotency plug is relies on this logs to send same result for duplicate requests with same `X-Idempotency-Key` headers.
  
  ### Monitoring
  
  To monitor services status we will use DogStatsD integration, that will receive following metrics:
  
  - `request_count` - (counter) [API](#reference/apis) hit rate.
  - `request_size` - (histogram) HTTP request size.
  - `response_count` - (counter) same as `request_count` but sent after request dispatch and additionally tagged with `http_status`.
  - `latency` (counter) - total request latency for a API consumer, additionally tagged with `http_status`.
  
  All metrics have tags: `http_host`, `http_port`, `http_method`, `api_name` and `api_id` (if matches any), `request_id`. This allows to set different aggregated views on counter data.
  
  <!--
  #### HTTPRelay
  
  _TBD v2.0_
  
  Send notification to a multiple upstreams, that is interested in perfoming async workload.
  
  There are several use cases for EventEmitters:
  
  - Notify marketing servervices on customer change/revenue events.
  - Notify services about data change, so they can take according actions. (Like sell offer remove.)
  
  Relay request to a multiple back-ends. Useful when you want to send multiple notifications when proxying request itself.
  
  Subsequent requests will
  
  #### Cache
  
  _TBD v2.0_
  
  Add plugin settings of [API](#reference/apis) to `X-Settings-Cache: json_encode(cache_plugin_setting)` header in all requests to upstream.
  
  #### Circout Breaker
  
  TBD 2.0
  
  ### Authorization
  
  All authorization plugins work on top of [Consumers](#reference/consumers/get-all-requests) entity. Plugins can assign access scopes that can be reused in [ACL](#reference/plugins/acl/get-all-requests) plugin.
  
  To authorize requests inside private platrom scope we can add `Authroization: Basic base64_token` headers, so services will know that request is sent from API Gateway. _In MVP release we will trust to all requests inside private zone, no API authorization is required._
  
  #### -oAuth-
  
  _This module will be used only in target architecture releases._
  
  Exchange `user_id` and `user_password` fields that is set in customer plugin settings to a oAuth access token, that can be re-used for futher requests.
  
  Other:
  
  - `user_agent_blacklist` - block requests by HTTP User Agent.
  - `cors` - _TBD 2.0_ allow to make requests from browser.
  - `ssl` - _TBD 2.0_ add SSL certificate for an API.
  - `ratelimit` - _TBD 2.0_ limit how many HTTP requests consumer can make.
  - `sizelimit` - _TBD 2.0_ block HTTP requests by body size.
  -->
  
  ## Installation
  
  Most simple way to install it is to use pre-built docker container available on [Docker Hub](https://hub.docker.com/r/nebo15/gateway/).
  
  You can deploy it to Kubernetes using [example configs from Annon's repo](https://github.com/Nebo15/os.gateway/tree/master/_k8s).
  
  # Group APIs
  
  ## Collection [/apis]
  
  You should create a separate API for each of your upstream back-ends. API's are extended by plugins.
  
  It is possible to use `api_name` instead `api_id` in any resource paths.
  
  ### Get APIs [GET]
  
  + Response 200 (application/json)
      + Attributes (Response_Collection)
          + data (array[API])
  
  ### Create API [POST]
  
  
negative.code: 
  # Annon API Gateway
  
  Annon is a configurable API gateway that acts as a reverse proxy with a plugin system. Plugins allow to reduce boilerplate that must be done in each service, making overall development faster. Also it stores all requests, responses and key metrics, making it easy to debug your application. Inspired by [Kong](https://getkong.org/).
  
  It's free. Source code is available on [GitHub](https://github.com/Nebo15/annon.api).
  
  > "Annon" translates from the Sindarin word for 'Great Door or Gate'. Sindarin is one of the many languages spoken by the immortal Elves.
  
  Annon consist of multiple main parts:
  
  - [Annon API Gateway](https://github.com/Nebo15/annon.api).
  - [Annon Dashboard](https://github.com/Nebo15/annon.web) - UI that allows to manage Annon settings, review and analyze Requests.
  - [EView](https://hex.pm/packages/eview) - hex package that allows to receive and modify client responses from Elixir application to match [Nebo #15 API Manifest](http://docs.apimanifest.apiary.io/). So your back-ends will respond in a same way as Annon does.
  - [Mithril](https://github.com/Nebo15/mithril.api) - authentication and role management service.
  
  ## Goals of the Project
  
  - Provide single management/monitoring system for medium-to-large scale applications.
  - Reduce amount of work needed in other componens by orchestrating common functionalities.
  - Control response time and get answer "what happened" even in a single request perspective. Provide data for in-deepth service analysis.
  - Improve platform scalability.
  
  ## General Features
  