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.
Apigee Architecture:
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:
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.
15. JavaScript: JavaScript is a policy that is used to perform JavaScript
functions in either the request or the response.
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 java development. In case you find anything tough
to perform, ask java programmers. They are readily available to solve
your queries
Reference Links:
