The API economy is growing rapidly, there are no two ways about it. According to estimates, APIs will, on a global scale, form a USD 2.2 trillion industry, by the end of 2018. Within the next two years or so, 3 out of every 4 Fortune 500 firms (on average) will start to operate and manage their very own application program interfaces. For big players like eBay, Expedia and Salesforce, APIs are already a major revenue source (60%, 90% and 50% respectively).
With the growing popularity of APIs both in the enterprise and the general domains, certain misconceptions about them have also surfaced. Lack of thorough knowledge can affect the standard of platforms created by API providers, and can hinder their optimal utilization by mobile app developers. Today’s discussion is divided in three sections – each being a FAQ section on the basics of REpresentational State Transfer (REST) APIs, OAuth2 security standard and the Apigee Edge platform:
REST APIs – FAQ
1) What is a REST API?
REpresentational State Transfer, or REST, refers to a lightweight architectural approach for the development and deployment of web applications and services. The simple URL-based (standard HTTP) structure of REST has contributed in it gradually becoming more popular than the XML-based SOAP (Simple Object Access Protocol) architecture. Any application program interface created by using REST standards is called a ‘REST API’ or a ‘RESTful API’.
2) Which HTTP methods are supported by REST?
POST and GET are the two simplest forms of HTTP methods in the REST architecture. The former submits the data that has to be processed, and generates the new information/resource. GET, on the other hand, is used for requesting a resource at the URL-level. From the request-URL, resources can be removed with the DELETE method, and updated with the PUT method. Metadata can be displayed with HEAD, while OPTIONS highlights all the methods/techniques used to access the concerned API.
3) Is there any rule regarding the naming of a REST API?
There aren’t as such any particular restrictions in this regard. However, from the design perspective, API developers typically recommend using ‘nouns’ (instead of ‘verbs’) in the base URL of the API. This practice goes a long way in preventing method calls from becoming confusing – owing to the presence of many related resources/objects – later on.
4) How important are the HTTP status codes in REST?
Extremely important. Incorrect usage of HTTP status codes can seriously hamper the performance/reliability of an interface – and can also introduce a lot of redundancy in the architecture. The following codes have to be used in the correct manner:
- 401 – to be returned when there are problems/errors in the input data.
- 404 – to be returned when the requested resource is unavailable.
- 201 – to be returned for a successfully created operation.
- 405 – to be returned when an inappropriate HTTP method is used.
- 400 – to be returned for bad requests.
- 403 – to be returned as a response to unauthorized access of resource.
Note: There are several other REST-specific HTTP codes. Read up on them before starting to work with the REST protocol.
5) What type of HTTP headers should be used?
That depends on the exact features and capabilities of the API under question. For instance, if you are building a platform that will support server-side response caching, ETag headers will be suitable for it. In general, API providers use either Accept-headers or Content-headers for platforms that are compatible with several data formats (JSON, XML, and others).
6) How is REST different from AJAX?
For starters, the REST protocol requires continuous interaction of the customer with the backend server – something that is not essential in the AJAX framework. Unlike REST, which is a software architecture style, AJAX is a technology set (for UI-updation dynamically). Responses in AJAX are created with JavaScript.
7) Which API library should be used for RESTful APIs?
JAX-RS is the standard API library that is invoked by developers for server-side communication (within the Java framework). For SOAP APIs, the standard library for communication is JAVA-WS.
8) REST or SOAP – Which one is faster?
Given its heavyweight nature, it is no surprise that SOAP APIs are typically offer slower performance than their REST counterparts. What’s more – the reads/responses in REST can be cached (not possible in SOAP). Compatibility with a much larger set of data formats (multiple in REST; only XML in SOAP) is another big advantage.
9) Is versioning important for REST APIs?
Yes, very much so. Apart from the API name and the names of operations, the version details should also be included in the API signature. Proper versioning ensures that the performance of the app (which uses the API) is not affected/broken when the API is updated. Even for new APIs, versioning is an absolute must.
10) What are the integration methods used in REST?
Asynchronous message swapping, database sharing and the batch file transfer mechanism are three application integration styles often used in the REST architecture. In certain cases, developers can also go with the Remote Procedure Call (RPC) process.
To get an insight into the need for API strategy optimization, click here.
OAuth2 – FAQ
1)What exactly is OAuth2?
OAuth2 is a popular authorization framework or protocol, relied upon by software developers worldwide. Through the framework, web and mobile applications can access information from user-accounts (to a limited degree). A good example of OAuth2 in action would be when apps request for certain access permissions from the social media account(s) of a user. OAuth2 is used for establishing the security standards of third-party desktop, web and mobile applications.
2) What are the ‘Tokens’ in the OAuth2 system?
Tokens, or ‘access tokens’, are used by the client-side applications to access and utilize information from user-accounts (a form of permissions). The tokens are generated by the server, following a validated request by the concerned third-party app. It should be noted that OAuth2 complements the Open ID protocol.
3) What are the defined ‘roles’ in OAuth2?
There are 4 specific ‘roles’ or ‘elements’ in the OAuth2 framework. The ‘Authentication Server’ is in charge of verifying and authenticating the owner of a resource, and delivering access tokens to external applications. The app itself is called ‘Client’ – and it has to be authorized and validated, before limited access to protected data is granted to it. The user is the ‘Resource Owner’, in charge of authorizing the permission requests and the degree of access. Finally, the ‘Resource Server’ is where all the user-account information is hosted.
4) What are the ‘grant types’ in OAuth2 authorization?
Once again, there are 4 different types of ‘grant’ available in the OAuth2 security system. For general login purposes, ‘Passwords’ are provided. ‘Implicit’ grants are given for web browser-based as well as mobile applications. For apps working on web servers, OAuth2 generates ‘Authorization Codes’. For actually accessing information, ‘Client Credentials’ are required.
5) What is a CSRF attack threat in OAuth2?
CSRF, or Cross Site Request Forgery, is a serious security threat that can affect OAuth approvals. The technique is used to access information from user accounts, without the consent of the concerned users. On the authorization server, hackers can validate authorizations to their own secure resources, and then manipulate the client redirects. To minimize CSRF-attack risks, state parameters should be bundled in with all requests to the authorization server.
6) How to register an application for OAuth2 service?
Signing your app up for OAuth2 support is fairly easy. All that you have to do is fill up the registration form (available from the website). Apart from the name of your app and its website (along with, maybe, a short description), you also have to specify a Redirect URL (where the app will redirect to, after the access permission is granted). Post-registration, a Client ID and a unique Client Secret are allotted to every user.
7) Apart from CSRF, are there any other security issues in OAuth2?
Unfortunately, yes. SQL injection, phishing and even owner impersonation are all fairly common methods for breaching the authorization framework. The good thing is, there are ways to avoid these risks as well. For example, using an encryption method while storing credentials does away with SQL injection threats. Provided that the servers have valid security certificates (i.e., on HTTPS), chances of phishing are also negligible.
8) What is the reason behind the presence of so many risks?
The security threats in OAuth2 do not stem from any weakness or loopholes in the framework itself. Rather, the problems can crop up due to improper implementation of the same. Note that, OAuth2 does not provide native security assurance and requires the support of other protocols (Secure Socket Layer, for instance) to ensure completely secure data exchanges.
9) How is OAuth2 different from OAuth1?
OAuth2 is a significant improvement over its predecessor, on multiple counts. Unlike OAuth1, it is not optimal for only desktop browsers – and can deliver equally robust authorization solutions for mobile apps (including gaming applications). OAuth2 is much more easily scalable than the earlier version as well. The base authentication system is also made simpler in Oauth2 (HTTPS in place of the confusing signature requests).
10) Do any of the big players in the IT domain use OAuth2?
Oh, yes…and how! From Facebook and Twitter, to Yahoo, GitHub and Google – most of the big players rely on Oauth2 to provide information from user-accounts on their servers (to third-party client apps). In fact, a key driver behind the launch of so many social networking apps in the recent quarters is the presence of the OAuth2 tool.
Apigee Edge – FAQ
1) What is Apigee Edge all about?
Apigee Edge is an advanced cloud-based API management tool/service. It is used to both create and manage API proxies, which, in turn, deliver a series of value-added services. Web and mobile app developers who need to use the backend are the primary customers of the proxies managed by Apigee Edge.
2) Are there any variants/packages of Apigee Edge?
Yes. The basic package is called Apigee Edge Start, while the pro-level package is called Apigee Edge Enterprise. The latter, understandably, has certain important additional features.
3) How secure is the Apigee Edge platform?
From the security perspective, Apigee Edge is right up there. It is compatible with the OAuth2 authorization framework (discussed above), and also has separate throttling rules to do away with replay risks. Developers can also prevent any particular IP address from accessing the API, with this tool.
4) What is the importance of the API Proxies created by Apigee Edge?
The proxies serve as an additional layer of authentication. They map the backend with a custom HTTP endpoint – doing away with the need of app-makers having to connect with the backend directly. Apigee Edge depends on these API proxies to optimally perform a wide range of tasks – right from authorization and monitoring, to data security and monetization.
5) Can custom codes be used in Apigee Edge?
The user-friendly extension policies of Apigee Edge ensures that app developers can use their custom codes without any hitch. Java, Javascript and Python are some examples of coding languages that can be used within the Apigee Edge system. Also, the tool makes the overall API development cycle shorter.
6) What are the main elements of Apigee Edge services?
Broadly speaking, the Edge services can be classified under the following three heads:
- API services – These include both the development as well as the consumption of APIs (by app developers).
- Developer services – These are all about managing the communities of internal and external developers who are using the backend services through API proxies.
- Analytics services – Errors, call information, latency and all other important metrics information related to APIs are collected and analyzed by the Apigee Edge analytics service. Short-term/long-term trends in these are studied as well.
7) Does Apigee Edge reduce the total amount of coding required?
Yes, the system does offer the ‘less-coding-to-do’ advantage for API providers. The basic structure of a REST-based API proxy can be created quickly – and there are many other customized configuration solutions available as well. Response message assigning, request variable extraction, OAuth policy execution – all tasks can be performed with ease, thanks to these XML-based configurations.
8) What is Apigee Edge on the cloud?
Apart from its ‘on-premises’ offering (officially known as Edge for Private Cloud), Apigee Edge also has a dedicated cloud-hosted version – which manages the overall cloud environment. This version operates like a software-as-a-service (SaaS). The cloud-version is available on both paid and free Apigee Edge accounts (unlike the on-premises version, which is available only on paid accounts).
9) How does Apigee Edge enhance API performance?
The ‘response time’ and the ‘per-second transactions’ are key indicators of the overall performance of any application program interface. Apigee Edge can boost this performance level, by either saving values in the memory cache, or by full response caching. The tool ensures seamless management of API calls, at all times.
10) Are there any built-in tools to convert JSON into XML?
With the help of built-in custom policies, JSON can be transformed into XML (and vice versa) on Apigee Edge. In addition, incoming data in any parameter (JSON, XML, other normal form parameters) can be easily parsed by the tool. Large media files can be streamed by Apigee Edge as well.
These are not, by any stretch of the imagination, exhaustive lists of all that there is to know about REST APIs, OAuth2 and Apigee Edge. However, going through the FAQs here will give you some idea about these products/tools – that’s for sure.