Do you know about Apigee and its uses?” The question stroke harder to java development team working with AegisSoftTech as most java programmers in the market are unaware of the power and features Apigee is having. Thus, to make them more acknowledged and enhance their expertise, we bring this article. They can learn about Apigee and its uses in development projects.
What is Apigee?
Consider the case where you have an API that yields some very useful information when requested. But the API requires some authentication to be performed, so that no hacker can use it, you want to enforce restrictions on the payload that the API can accept, some mandatory variables that are expected, null pointer checks, garbage data check, some specific format of the request payload, the different types of responses such as xml and json and many many more things that you might want to be in your API. In common way, one would code all these checks into the API to filter every request before it actually hits the DB for any data. One will write the code for every custom functionality.
Though this is a correct approach, it is still not advisable to do so. This involves a lot of overhead on the part of the API. Every single time, it has to execute code on every incoming request. Say for eg., the API will only accept a JSON payload whose array does not have more 10 elements. We will include this check in the code. Now for example, the JSON request has 20 elements in the array. Though the request will be rejected, the code still has to check the entire payload to verify that it indeed has more than 10 elements. This adds to the overhead on the part of API and the developer.
What if there was an intermediate layer that takes the responsibility of these mundane tasks. What if it takes all the responsibility to perform all the checks on the request i.,e Authentication, Request payload checks, validation checks, converting the response into different formats, etc. Will it not make coding the API much more simpler and soluble removing it from all the cluttered code for various checks. Here Apigee comes to the rescue. Apigee is a software solution meant to separate all these tasks from the actual API thus enabling the creation of clean and clear API code and enables the developer to instead focus on the core business logic of the API. Apigee guarantees to handle the rest.
How To Access Apigee?
Go to http://www.apigee.com and login with the credentials. Once logged in, go to the API management console. In order to create an api in Apigee, we need to create a new API proxy as follows.
Once clicked on + API Proxy, the following popup appears
The Starting point shall be selected as a Back end Service. This type means that we already have a back end service with us and we want Apigee to handle the rest of the chores. We can also build a new service from scratch but we are not going to discuss it here.
In the 2nd field, the Back end Service URL field, we have to enter the actual URL of the API that we have. Keep the project base path as /. Add some description if needed and click on Build. Clicking on build will create a new API proxy and deploy to Apigee. The following screen is shown post that:
Note: Once an API proxy has been created, the URL that any consumer will hit in order to access the data will not be the one that we entered in Back end Service URL field while creating the proxy anymore. The URL now will be the URL in the Deployments section as shown above. It is an Apigee URL. Internally when a user hits this url, the request is routed to the actual service via Apigee, thus enabling Apigee to perform all the functions and chores before actually hitting the service.
Let us understand some technical jargon associated with Apigee before moving forward with creating an API proxy:
1. API Proxy: An API proxy is an intermediate facade to the actual service back end. API proxy is actually responsible for handling all the menial chores such as authentication, verification, preventing from spam attacks, etc. API proxy achieves this by adding a series of policies to the proxy
2. Products: An Apigee product is a group of API proxies. Each product can define the access to each of the proxies defined under it.
3. Developer: A Developer is a consumer who wants to access the back end service via the Apigee API.
4. Developer App: A Developer App is a product of the developer who wants to gain access to one or more API products and in turn the API proxies.
Developing an Apigee proxy:
Now once an API proxy has been created, we want to add all the common functionality that we discussed earlier to it. In order to do that, we need to go to the Develop section in the above figure and click on New Policy as shown below:
Before moving forward one might ask the question as to where should I be adding the different functionality to be performed. A request to an API and a response to an API is divided as follows:
The proxy endpoint lies on the Client end and the Target endpoint lies on the Service end. Whatever policies we define here has to be decided as to where they should be placed. For eg., placing a policy on the pre-flow part of Proxy endpoint in the Request, means that any request coming in has to always first pass through the policy and then only it can move forward. Where to place the policy in the flow is a business requirement. It depends on how do we want the functionality to execute, at what place do we want the policy to execute, etc. The policies can be added at any one point in the flow:
1. Pre-flow Proxy Endpoint Request
2. Post-flow Proxy Endpoint Request
3. Pre-flow Target Endpoint Request
4. Post-flow Target Endpoint Request
5. Pre-flow Proxy Endpoint Response
7. Pre-flow Target Endpoint Response
8. Post-flow Target Endpoint Response
The policies that actually help in maintaining all the routine tasks are described as follows:
1. Spike Arrest: Spike Arrest is a policy which limits the number of requests that actually reaches the back end service. This is particularly useful when we know that the server is capable of handling only certain amount of requests or we do not want any sudden spikes in requests to the server.
Suppose say the value for Spike Arrest is set to 60 requests per second. Internally, Apigee breaks down the number of requests to a time unit one step lower than the specified limit. Here, Apigee breaks the limit to 1 request per millisecond. So even if there are 5 requests in 1 millisecond and no requests for another 10 millisecond, the policy wont allow because internally it sets a limit to 1 request per millisecond.
In generic times, Spike Arrest divides the number of requests in a time unit that is 1 step lower than the specified time limit.
2. Response Cache: The cache mechanism operational here works much in the same way as the cache in normal language. For very frequent calls to the API, Apigee stores those particular responses in a cache so that any more request to that call will be responded directly from the cache and not hit the back end.
3. Basic Authentication: Basic Authentication is a policy that is used when the back end service mandates an authentication. In Basic Authentication, we have to pass a User name and a Password in the header. The header contains a field called 'Authorization'. Its value is set as Base64 encoded value of (username:password). The back end service interprets this as an authentication mechanism and acts accordingly.
4. XML Threat Protection: XML threat protection is a policy that helps to prevents requests that contains unusually long xml payloads and which is interpreted as dull requests or hacker requests.
5. JSON Threat Protection: JSON threat protection works in a pretty similar way. It helps to prevent requests that contain unusually long json payloads and which is interpreted as dull requests or hacker requests.
6. Regular Expression Protection: Regular Expression protection is a policy that helps to prevent requests containing a certain pattern in the URL which are interpreted as dull requests or hacker requests.
7. Verify API Key: Verify API key is a policy that is used for authentication purposes. Unlike Basic authentication, that mandates the usage of Username and password sent in the header, API key requires the passing of a Consumer secret key along with the request. The secret key is generally passed along with the URL to the backend in the form of apikey=<actual key>. The variable name can be changed/configured as per whatever is required.
8. Access Control: Access Control is a policy that is used to filter the requests that reach the target. Suppose we want to allow only a certain range of IP's and reject another set of IP's, we have to use an Access control policy which specifies which range of ip's to ignore or accept.
9. JSON to XML: Consider the case wherein the user requests for a JSON or an XML response. The back end service that has currently been written only responds with a JSON. We do not intend to change the response of the response yet we want to return the XML response when the user requests for it. This policy comes into picture here. This policy converts the JSON to XML when the user requests for it.
10. XML to JSON: This policy is exactly similar to the previous one except that it converts the XML response to a JSON one when requested by the user.
11. Raise Fault: Raise Fault is a special type of policy that is used to raise a fault to indicate that something has gone wrong. In usual circumstances, we have the back end handle all the erroneous tasks and return with some sort of error to the user explaining him the reasons. If we do not intend to handle the errors at the back end, we can handle them at Apigee level. By using the Raise Fault policy, we can indicate of an erroneous situation and return the response from Apigee itself with a proper error code and an error message that is easily understood by the caller.
12. Assign Message: As the name suggests, Assign Message is a policy that is used to assign a value to a variable. There may be circumstances wherein it is required to assign some value to the variable either in the request or in the response received. Assign Message policy is used at such a time which assigns any custom value to a variable.
13. Extract Variables: Extract Variables is a policy used to extract a variable from either the request or the response. In most common cases, Extract Variables is generally followed by Assign Message because it might be quite a common scenario to assign some value to variable. In that case, the variable is first extracted using the Extract Variables policy and a value is then assigned to it using Assign Message policy.
14. Key Value Map Operations: Key Value map Operations is a policy that works much similar to a Hashmap in Java. It stores a key and a value that can later be retrieved for any custom purposes.
16. Service Callout: Service Callout is basically used when there is a need of calling another service from within the request in order to fetch additional information without the user knowing the fact that the final response is indeed coming from two different back ends.
Hope you get the concept right and will make best practices for . In case you find anything tough to perform, ask java programmers. They are readily available to solve your queries