Benefits Of Web Apis Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Many companies, government agencies, organizations, and individuals have an interest in the success, growth, and value of their organisation. The internet has reached the critical mass and has become the dominant means of communication and commerce.

Web 1.0

Since the introduction of the World Wide Web, companies have set up web sites and provided users with information. What these websites lacked was complexity.

Web 1.0 sites are static. The information contained in these websites does not change and therefore there is no reason for a visitor to return to the site at a later stage.

Web 1.0 sites are not interactive. Most organizations have profile pages that visitors can look at but not impact or alter.

Web 1.0 applications are proprietary. The Web 1.0 philosophy does not promote the sharing of knowledge and tries to retain exclusivity. Therefore each time an organisation or individual wants to create a web service they have to re-invent the wheel.

Web 2.0

Bulletin boards, online forums, personal web pages with guest-books, and chat rooms appeared. These sites enabled people to ask questions, make statements, share information, and debate on various arguments. These new forms of communication have given rise to what we call nowadays Web 2.0.

Although the term Web 2.0 suggests a new version of the World Wide Web it does not refer to an upgrade of any technical specifications but to changes of how software developers and end users make use of the web. There is no exact description of Web 2.0, but most people agree that it involves making new and improved forms of online connections between:

…two or more people

Consumer Generated Media is about using online technologies to connect people to each other in a social network or business teams. Examples of Consumer Generated Media are social networking sites, wikis, blogs, and online videos. Websites such as Facebook, MySpace, Wikipedia, Blogger, and YouTube allow anybody to add as well as to access content, to leave messages and comments, and to exchange digital media including photos and videos.

…individual users and software applications

Software as a Service is the application functionality being offered directly over the internet. In turn user data and applications can then be accessed from any internet enabled computing device. In simple terms it's like having all the work packages installed in a desktop available online. Therefore using them will not require the user to install them. For some years human resources and project management applications have been successfully offered over the internet. In recent years, online replacements for personal desktop applications have also been made available. For example, GoogleDocs is an online word processing, spread sheet and presentation package available for free over the web.

…two or more online services

Web Application Programme Interfaces are components of an online functionality which can be plugged together in order to create an integrated online system or Mashups. For example many companies use the web service of a payment service provider such as PayPal to allow them take online credit card payments. This results in customers interacting with two organizations that are automatically interlinked via the internet. A number of Mashups are facilitated by these APIs and this is a big tenant of Web 2.0.

Key Benefits of Web APIs

Reach & Relevance

The size of the web is continuously growing. On the bright side this growth brings with it an increased number of possibilities to promote products and services. On the other hand it is becoming more difficult to get noticed.

With Web 2.0 the website owner has the option to provide the functionalities which its website make use of, to third parties through an API. An API is wired through the infrastructure of a company, thus giving access to invocations which return what was previously considered as 'private' data. Thus, the website owner opens a gateway through which the data, and the functionality it provides, can be retrieved and used on third party websites. As a result a website owner increases the possibility of users making use of its functionality and therefore reaching a larger client base.

Third parties will only make use of functionality if they are relevant to the services provided in their websites. In a nutshell an API allows our website owner to reach a client base interested in its functionalities and therefore increasing traffic.

Providing access to their services via APIs has been a major winner for several companies: Twitter and Flickr just to name a few. These companies have managed to gain platform leadership - and their API plays a crucial role in that. Many other companies are following suit: from e-commerce over content & media, business services to the government

APIs provide a key enabler that allows Internet businesses to go beyond their own website and try to be visible on every other website.

New distribution channel

APIs can simply be seen as a new distribution channel. While the original website is usually the main channel. APIs allow to reach, promote and sell the company's content or functionality to other websites.

Innovation & Synergies

Through APIs a website owner will have its content and functionalities available on a number of third party websites. Moreover, other website owners may decide to effect further enhancements to the content and functionalities retrieved with the possibility of making it more attractive and useful. The API holder will then reap the benefits because more traffic is generated, and more importantly, there is more user activity in the site. Such added value is achieved at no extra cost for the API holder. Thus resulting in a very cost efficient sales and marketing tool.

Creating a website can either be done by paying a developer or Mashup content and functionalities provided by several APIs. This might seem as being a typical example of free-rider principle. However this is not the case, since the original website would be continuously marketing itself.

Due to flexible integration and re-usage of content & functionality on the web, APIs foster innovation. The next major evolution cycle of the Internet will be a web, mashed-up from various sources of raw data, exploiting synergies to create something new with additional value added.

API Terms and Conditions

An API allows the public to access on line data in a controlled manner. Any user wanting to make use of an API is given a unique key. What can be accessed and retrieved is determined and monitored by an API and is limited per key. Users send a request for data retrieval to the API, this in turn confirms whether the user is authorised to access such data. If the user is authorised to access such data, then the API will allow the user to retrieve data from the library. This data will have to be passed through the API so that the user can take data which can be clearly read and understood.

Every Community providing an API to developers has an API agreement policy which states their own terms of use. Samples of these terms are given below:

Google Map API

In using Google Brand Features, you will not:

(i) display a Google Brand Feature in any manner that implies a relationship or affiliation with, sponsorship, or endorsement by Google, other than your use of the Service, or that can be reasonably interpreted to suggest editorial content has been authored by, or represents the views or opinions of Google or Google personnel;

(ii) use Google Brand Features to disparage Google, its products, or the Google Services;

(iii) display a Google Brand Feature in your Maps API Implementation or on your site if your Maps API Implementation or site contains or displays adult content or promotes illegal activities, gambling, or the sale of tobacco or alcohol to persons under twenty-one (21) years of age;

(iv) have the Google logo as the largest logo in your Maps API Implementation or on your website (except as displayed in the map image itself);

(v) display a Google Brand Feature as the most prominent element in your Maps API Implementation on any page of your website;

(vi) display a Google Brand Feature in a manner that is misleading, defamatory, infringing, libellous, disparaging, obscene or otherwise objectionable to Google;

(vii) display a Google Brand Feature in your Maps API Implementation or on a site that violates any law or regulation; or

(viii) remove, distort or alter any element of a Google Brand Feature (this includes squeezing, stretching, inverting, discolouring, etc.).

Not sure that copying and pasting the conditions here is a good idea - a summary of the main concepts would have been more appropriate

NY Times API

Unless otherwise consented to or permitted by NYTIMES.COM, you will:

(i) not modify or edit any content, headlines, links or metadata included in the API content when presenting it on your Site;

(ii) ensure that the fundamental meaning of the API content is not changed or distorted;

(iii) ensure that the use or display of API content does not suggest that The New York Times promotes or endorses you or any third party or the causes, ideas, Web sites, products or services of you or any third party;

(iv) not display the name, logo, trademark or other identifier of another person (except for NYTIMES.COM or you) on your Site in such a manner as to give the viewer the impression that such other person is a publisher or distributor of the API content on the Site

(v) not archive any of the API content for access by users at any future date after you have finished using the service or if your account is terminated.

Ensuring Compliance to the API Terms and Conditions

Security to the API provider, is limited to traffic data management, i.e. the API provider at most requests an Authentication key in order to be able to access and take hold of API data. Many Internet businesses have not yet done the switch from an open API (without access control) to a managed API (with access control).

However, at present the Product Manager has no means to confirm whether the Terms and Conditions of use are abided to, other than manually accessing the website and verifying whether its contents are compliant. This means that once the data is being given to the users, the Product Manager has no control of it and the user/client can amend and manipulate the data to one's discretion.


The solution proposed is one which addresses this problem at runtime, where a web based application is made available to both the API companies and users willing to make use of specific API content. The application will act as an intermediary between an API and the client. The intermediaries' main concern will be the licence restrictions required by the API provider.

A sample prototype of the actual application has been developed as explained by the below diagram:



Web Application

(Terms & Conditions)










An API Provider wanting to enforce the API Terms and Conditions will logon to the Sandbox Web Portal. This application will provide the project manager with a list of security constraints to choose from. He will in-turn select the security constraints to be invoked for specific API calls.

These security options, which are linked to specific events and to a specific API, are then used in such a way as to create a JavaScript Application, known as the Sandbox which will be deployed onto a Proxy dedicated to that specific API. The Proxy will not include the API content itself, but rather it redirects the API request to the API provider. The Online Application will act as a proxy which will filter out "malicious" requests.

From now onwards, API providers will be giving out a new API URL which will be that of the Proxy server. As a client invokes a request to the API, this will be directed to the proxy.

The proxy will send the request with some added verification details to the API.

The API will send back the data requested by the client to the proxy.

The proxy will send the data provided by the API together with the security measures linked to the request done by the Client. From the client point of view, once the user has requested API content, the intermediary will send the sandbox to the website which requested the API content and will check for the Security Restrictions provided by the API provider. If the website is compliant to these Security Restrictions, the sandbox will provide the user with the data requested; else no data is given to the user.

Prototype Testing

The major problem perceived in enforcing the API Terms and Conditions was the use of IFRAMES. An IFRAME is an HTML document embedded inside another HTML document on a website. The IFRAME HTML element is often used to insert content from another source, such as an advertisement, into a Web page.

This test case was taken into consideration since the use of IFRAMES can 'fool' the Sandbox, in such a way as to make it believe that the data in the website is compliant with the API Terms and Conditions. While in reality, although the data retrieved by API is placed in an HTML document which is compliant to the Terms and Conditions, the various other HTML documents embedded in the same website are not.

The prototype worked successfully, i.e. the Proxy embeds the JavaScript linked to the event to be invoked. As the client makes a request to the Proxy, it requests the data from the API, wraps the JavaScript sandbox around it and sends it to the client. As soon as the data arrives to the user, the JavaScript is executed and checks for the objects within the website which are not desired. This is affected by using Document Object Model functions (DOM). The JavaScript has been able to detect the IFRAME and other contents successfully and thus refusing to show the data requested by the client.

By producing a simple prototype of the application, several other problems which must be addressed have arisen. Case in point, a client may try to bypass the sandbox by intercepting it and changing values within the JavaScript at runtime. This will in-turn override the JavaScript Sandbox and the data sent by the API is shown on the browser even though the website does not comply to the API Terms and Conditions. Such outcomes might change the way the application handles the flow of data between the API, Proxy and the client.

Prototype Evaluation Technique

A number of JavaScript professionals will be given the prototype to test how easy it is to crack the code. They will try to override the Terms and Conditions associated to the API. Such as showing data and information next to the API web content which is not desired by the API.

Thus, these professionals will try to show the data provided by the API even though the web content is not desired.




sandbox Website Design and Implementation

2 wks. 2 days

Design and Implementation of the Web portal for API providers

9 days

Designing and Implementation of the Web portal for API clients

9 days

Implementation of Proxy logic and Proxy provider

1 wk.

JavaScript sandbox Design and Implementation

2 wks. 4 days

Design and Implementation of generic API terms and conditions

1 wk.

Design and Implementation of Implementing the sandbox creator

1/2 wk.

Implementation of sandbox security measures

1 wk.


1 wk.

Debugging and Test Runs

1 wk.


5 days

Monitor JavaScript professionals' actions

3 days

Evaluate results obtained

2 days


4 wks.

Writing of the Technical Report

4 wks.