anchor.diff:  === Apiman at Runtime - Proxying Requests
   What happens is that when an API request is received by the API Gateway at runtime, the policy chain is applied in the order of client app, plan, and API. If no failures, such as a rate counter being exceeded, occur, the API Gateway sends the request to the API. In order to be accepted by the API Gateway, a request must include an API key. The API Gateway acts as a proxy for the API:
   
  -image::images/apiman_002.jpg[apiman at runtime]
  +image::images/apiman_002.png[apiman at runtime]
   
   Next, when the API Gateway receives a response from the API’s backend implementation, the policy chain is applied again, but this time in the reverse order. The API policies are applied first, then the plan policies, and finally the client app policies. If no failures occur, then the API response is sent back to the consumer of the API.
   
  
positive.code: 
  To configure the API, we’ll first create a plan to contain the policies that we want applied by the API Gateway at runtime when requests to the API are made. To create a new plan, select the “Plans” tab. We’ll create a “gold” plan:
  
  image::images/11.png[ExampleImage_11]
  
  Once the plan is created, we will add policies to it:
  
  image::images/12.png[ExampleImage_12]
  
  apiman provides several OOTB policies/plans. Since we want to be able to demonstrate a policy being applied, we’ll select a Rate Limiting Policy, and set its limit to a very low level. If our API receives more than 10 requests in a day/month, the policy should block all subsequent requests. So much for a “gold” level of API!
  
  image::images/13.png[ExampleImage_13]
  
  After we create the policy and add it to the plan, we have to lock the plan:
  
  image::images/14.png[ExampleImage_14]
  
  And, here is the finished, and locked plan:
  
  image::images/15.png[ExampleImage_15]
  
  At this point, additional plans can be defined for the API. We’ll also create a “silver” plan, that will offer a lower level of API (i.e., a request rate limit lower than 10 per day/month) than the gold plan. Since the process to create this silver plan is identical to that of the gold plan, we’ll skip the screenshots.
  
  Now that the two plans are complete and locked, it’s time to define the API.
  
  image::images/16.png[ExampleImage_16]
  
  We’ll give the API an appropriate name, so that providers and consumers alike will be able to run a query in the API Manager to find it.
  
  image::images/17.png[ExampleImage_17]
  
  After the API is defined, we have to define its implementation. In the context of the API Manager, the API Endpoint is the API’s direct URL. Remember that the API Gateway will act as a proxy for the API, so it must know the API’s actual URL. In the case of our example API, the URL is:  +++<u>+++http://localhost:8080/apiman-echo+++</u>+++
  
  image::images/18.png[ExampleImage_18]
  
  The plans tab shows which plans are available to be applied to the API:
  
  image::images/19.png[ExampleImage_19]
  
  Let’s make our API more secure by adding an authentication policy that will require users to login before they can access the API. Select the Policies tab, and then define a simple authentication policy. Remember the user name and password that you define here as we’ll need them later on when send requests to the API.
  
  image::images/20.png[ExampleImage_20]
  
  After the authentication policy is added, we can publish the API to the API Gateway:
  
  image::images/21.png[ExampleImage_21]
  
  And, here it is, the published API:
  
  image::images/22.png[ExampleImage_22]
  
  OK, that finishes the definition of the API provider organization and the publication of the API.
  
  
negative.code: 
  This diagram lets us visualize how the two policies will work together:
  
  image::images/apiman_005.png[policies working together]
  
  In this diagram,  each filled in box represents one API request. The important thing to understand is how the policies work together to enable you to have flexible throttling of requests to your API:
  
  