Introduction to Apigee

Apigee is a platform for developing and managing APIs. With Apigee, you can build API proxies—RESTful, HTTP-based APIs that interact with your services. With easy-to-use APIs, developers can be more productive, increasing your speed to market.

 A cloud version hosted by Apigee in which Apigee maintains the environment, allowing you to concentrate on building your services and defining the APIs to those services

An API proxy is your interface to developers that want to use your backend services. Rather than having them consume those services directly, they access an Edge API proxy that you create. With a proxy, you can provide value-added features such as:

1.Security                      

2.Rate limiting                        

3.Quotas                           

4. Caching & persistence

5.Analytics                     

6. Transformations                    

7.Fault handling                

And so much more...

API proxies give you the full power of Apigee's API platform to secure API calls, throttle traffic, mediate messages, control error handling, cache things, build developer portals, document APIs, analyze API traffic data, make money on the use of your APIs, protect against bad bots, and more.

Apigee consists of the following primary components:

Apigee services: 

The APIs that you use to create, manage, and deploy your API proxies.

Apigee runtime: 

A set of containerized runtime services in a Kubernetes cluster that Google maintains All API traffic passes through and is processed by these services.

In addition, Apigee uses other components including:

GCP services: 

Provides identity management, logging, analytics, metrics, and project management functions.

Back-end services: 

Used by your apps to provide runtime access to data for your API proxies.

Companies today want to make their backend services available on the web so that these services can be consumed by apps running on mobile devices and desktops. A company might want to expose services that provide product pricing and availability information, sales and ordering services, order tracking services, and any other services required by client apps.

Companies often expose services as a set of HTTP endpoints. Client app developers then make HTTP requests to these endpoints. Depending on the endpoint, the service might then return data, formatted as XML or JSON, back to the client app.

The client apps that consume these services can be implemented as standalone apps for a mobile device or tablet, as HTML5 apps running in a browser, or as any other type of app that can make a request to an HTTP endpoint and consume any response data. These apps might be developed and released by the same company that exposed the services, or by third-party app developers who make use of publicly available services.