apis from idea to market - amrsalah.techamrsalah.tech/mwcwp/wp-content/uploads/2018/03/APIs-from-IDEA-to... · Backend services ... SWAGGER, RAML) APIS FOR DEVELOPER & ARCHITECTS

APIS FROM IDEA TO MARKET

Developing & Securing APIs Best Practices

Amr Salah - Middleware Specialist [email protected]

Linkedin

Abstract

This document will go deeply with list of definitions, approaches and best practices to develop and secure APIs. The document discusses the recommended development lifecycle

with market tool as well as security best practices for APIs and the whole environment

https://www.linkedin.com/in/amr-salah-a35376b/

APIS FOR DEVELOPER & ARCHITECTS

Amr Salah - Middleware Specialist

1

EXECUTIVE SUMMARY

Nowadays, APIs is the integration cornerstone technology. APIs continue to be an

integral business strategy across industries, and it doesn’t appear to be slowing

down anytime soon, especially with the rise of IoT.

Moreover, the systems integration pattern into large and medium organisations

derives its value from being able to connect all systems together, transform data,

automate end-to-end solutions to your customers and expose all your functionality

in very secure way.

Furthermore, APIs is very cheap technology to use, while cloud vendors provide us

today with pay-as-you-go model, we have also serverless which is cheaper and

charge you by request/response only.

Additionally, it’s aligning with agile methodology in which incremental shippable

releases are delivered to the customer every one to four weeks with a great

potentials to quick growth.

Last but not least, APIs is very easy to develop with a guarantee to deliver a flexible,

secure, high quality, well written, well documented and professional integration

solution if you have the right architecture in place.

In this document, we will dive

deeply into APIs technologies,

approaches, architecture and

security starting by APIs

definition and comparison,

APIs development best

practices ending with securing

the whole environment not

only APIs.

CONTENTS

The ability of your business to change quickly,

innovate easily, and meet competition wherever it

arises is a strategic necessity today. This will allow

you to thrive in a market which constantly

changes, and create new customer experiences in

new contexts using new technologies.

Mulesoft - Microservices Best Practice



2

Executive Summary ............................................................................................................................................... 1

APIs introduction................................................................................................................................................. 4

RESTful APIs Lifecycle .......................................................................................................................................... 6

APIs Design........................................................................................................................................................ 7

What is API Design & Why? ........................................................................................................................ 7

APIs Documentation tools ........................................................................................................................... 7

APIs Development .......................................................................................................................................... 10

Backend services ........................................................................................................................................ 10

APIs Development Golden rules .............................................................................................................. 12

APIs Interface Naming .............................................................................................................................. 13

Development tools ..................................................................................................................................... 15

APIs Testing ..................................................................................................................................................... 17

APIs testing types ....................................................................................................................................... 18

Testing phase preparation ...................................................................................................................... 20

APIs Deployment ........................................................................................................................................... 22

Deployment Server Types ....................................................................................................................... 22

APIs Management .......................................................................................................................................... 23

Security ....................................................................................................................................................... 24

Throttling & Limiting .................................................................................................................................. 25

Validation & Mapping (Interface Management) .................................................................................. 25

Routing........................................................................................................................................................ 25

Deployment & Publishing ......................................................................................................................... 25

Logging & Monitoring ............................................................................................................................... 25

APIs Gateways Solutions......................................................................................................................... 26

APIs Publishing, Discovery & Consuming .................................................................................................. 28

API Discovery & Consuming .................................................................................................................... 28

APIs Development FAQ ...................................................................................................................................... 29

APIs revenue models ............................................................................................................................................ 31

API Security .......................................................................................................................................................... 32

Authentication & Authorisation ................................................................................................................ 33

Infrastructure hardening ........................................................................................................................... 35

Data, Host & Network Security ................................................................................................................ 36

DATA/Host/Network Security Tips ......................................................................................................... 44

High Availability ....................................................................................................................................... 45



3

Logging & monitoring, .............................................................................................................................. 48

Risk Management ..................................................................................................................................... 49



4

APIS DEVELOPMENT

APIS INTRODUCTION

Long time ago people started to use SOAP Webservices which enabled system

integrations regardless backend technologies, e.g. Java systems are talking to C#.

This was very powerful in large organisations where they have a lot of implemented

system from different

companies and want to

integrate all of them together.

SOAP webservices worked well

and fit in all cases until we had a

RESTful APIs which is

HTTP/HTTPS based.

Unlike SOAP webservices which

is XML-based and requires a lot

of effort to develop and use,

RESTFul APIs are very easy to

develop and can be consumed in a browser as (HTTP request)

So quickly let's put SOAP vs REST comparison

SOAP VS REST

SOAP is XML-based, REST is JSON-based which makes REST much lighter

(SOAP–0 vs REST-1)

SOAP only supports XML, REST is support XML & JSON (SOAP–0 vs REST-2)

SOAP is not supported by browser, REST is HTTP based so it's fully supported

by browser (SOAP–0 vs REST-3)

REST provide great performance, usually through caching information which

is not altered (SOAP–0 vs REST-4)

REST is usually faster and use little bandwidth than SOAP (SOAP–0 vs REST-5)

A lot of scripting language is available for developing REST which facilitate the

development much more than SOAP (SOAP–0 vs REST-6)

REST is supported by a lot of technologies will talk about it later and it's very

easy to learn. Learning curve is very low (SOAP–0 vs REST-7)

XML vs JSON

https://www.w3schools.com/xml/default.asp

https://www.w3schools.com/xml/default.asp



5

REST is Stateless, SOAP supports both Stateless and Statefull which give 1

point to SOAP (SOAP–1 vs REST-7)

Most of SOAP products provide adapters for integrating with different

systems which gives another point to SOAP (SOAP–2 vs REST-7)

REST & SOAP are supporting versioning

REST is callable by Mobile applications

One very important point which is RESTful APIs enable developers to deliver

frequently functioning releases to production every one to three weeks. Although

SOAP enables the same functionality but SOAP complexity against RESTful disable

the easiness of this model.

Figure 1: Iterations - Agile Model

Finally, the good news is all companies they provide SOAP-based solutions enabled

RESTful endpoints as an extension which implies the world agreed that Restful APIs

are the most efficient and powerful for the time being.



6

RESTFUL APIS LIFECYCLE

Figure 2: Mulesoft Model - APIs Life cycle

Although there are no standards for the REST architecture, but the market provided

us with high level architecture leads to a clear lifecycle for developing high

availability, secure, well designed, well documented, flexible, reliable and extensible

APIs.

Of course, different vendors have different thoughts and implementations, but

mostly all vendors and developers agreed to follow below structure.

Figure 3: Oracle Blogs – Oracle API Platform lifecycle



7

APIS DESIGN

Role: API Developers/Managers/Architects

WHAT IS API DESIGN & WHY?

Design APIs process is the cornerstone of developer APIs. If APIs are mostly used for

integration, it means we have bunch of users will interact with developed APIs.

Hence, we need to have a very clear documentations for all the developed services

including:

1- Available Services (End points/Interfaces)

2- Allowed HTTP methods (GET/POST/PUT/DELETE/PATCH/etc) linked with

available operations

3- Input & Output payload per operation, which is the expected input & output

for each services

4- References, which is kind of objects used in payload

5- applied validation on process so consumers can consider

6- required security for accessing

7- Testing use cases.

Clear APIs documentation is not an optional anymore and it’s never been an

optional, but when it comes to an integration then documentation is as important

as development and delivery.

GOOD NEWS & HOW?

1. APIs documentation is an English translation to your APIs specification in a

common syntax. Once documentation in written in good format, APIs will be

generated from written specification. Developers can add more activities to

integrate with backend.

2. Most of documentation tools are supported by APIs development tools.

APIS DOCUMENTATION TOOLS

There are few documentation tools for free. Each of them has a syntax to describe

and design your APIs in very professional way. Whichever you choose, will do the

job, but you have to learn one of them to deliver strong APIs and strong

documentation. Also most of them are available on cloud so you can Document,

Save & publish in one place. (E.g. SWAGGER, RAML)



8

SWAGGER (Open API)

Below syntax is describing a service with interface (/users) to add a new user (id:

10, Name Jessica Smith and the response in case of success will be 200 ‘OK’)

Figure 4: https://swagger.io/

https://swaggerhub.com/blog/api-design/design-first-or-code-first-api-development/



9

RAML

Below syntax is describing a service with interface (/songs) which is list songs

using GET method by passing songTitle as parameter to filter list of available

song and response with ‘200’ and below payload in case of success.

Figure 5: https://raml.org

In addition to multiple frameworks

1- API Blue print

2- Apiary by Oracle

3- Mulesoft

https://raml.org/developers/raml-200-tutorial

https://apiblueprint.org/

https://apiary.io/

https://www.mulesoft.com/resources/api/guidelines-api-documentation



10

APIS DEVELOPMENT

Role: API Developers

Development is the first or second step after APIs design and documentation. In this

section we will talk about services development, APIs Interface Naming and

development tools.

BACKEND SERVICES

Figure 6 http://www.robert-drummond.com

Backend Services Types

There are different types of backend services can be wrapped into APIs

Adapters & Connections

Figure 7: http://www.ateam-oracle.com



11

Adapters are built-in components into many products (e.g. OSB, Mulesoft)

enable developers to create connections to different systems (e.g.

Oracle/MySQL Database, Salesforce Cloud, AQ /JMS messaging systems,

FTPS/Files, Healthcare/B2B systems, SAP/ERP, Siebel/CRM, etc.).

This connection is usually created using built-in adapter provided by the

product you are using, developer prepare required data, send it to adapter,

get result back from system and then send it back to consumers.

RESTful APIs

Figure 8: http://6ix-ta.com

In some cases RESTful APIs used as middleware layer between two systems.

Generally, intermediate/middleware layer is used to expose an isolated

services to public internet, e.g.

1. Call Facebook APIs

2. Call Google Calendar APIs to be synced with our app calendar

3. Call an internal system developed by different team and isolated from

DMZ public internet

Business Processes

Business processes are everywhere today and based on the product you are

using you might be able to use adapter to trigger process directly like (Oracle

Cloud Process/Integration) or you might need to expose it first to a rest

service.



12

SOAP-Based

Figure 9: https://wso2.com

Last but not least, this is when a SOAP based product like (Oracle SOA suite,

BPM) is exposing SOAP end point by default in the same time adding an

extension to expose this SOAP endpoint to a RESTful.

APIS DEVELOPMENT GOLDEN RULES

There general rules must be considered during development process:

1- Log functionality, there is a minimum level for logging which is part of

security requirements in addition to logging for business needs.

2- Reporting & Alerting, Incidents must be captured into your code, alerted and

reported via email, SMS to administrator based on the severity level.

3- Unique Identifiers, each request must has a unique identifier captured with

log details or in case of alerting. This unique identifier helps in assessing the

issue and fixing it quickly.

4- Data transformation, in most APIs data transformation is required and using

one method for transformation (e.g. XQuery, DataWeave) add a consistency

to code as well as comments.

5- Canonical model, it’s highly recommended to use canonical model to transfer

data between services and systems which guarantee consistency as well as

easiness of development. It must be well defined from the begging.



13

6- AQ/MQ, is another approach of developing stateless restful services and

highly recommended for performance improvement, but it’s all depends on

design decisions and business requirements because it has drawback (e.g.

losing the communicated message)

7- Retry Mechanism, If APIs are integrating with different systems, then retry

mechanism when stablishing connection is quite important to avoid a lot

instances failure.

APIS INTERFACE NAMING

Figure 10: https://www.ntu.edu.sg/

Whichever the backend is, there is only one way to expose your service as RESTful

which is give it a (URI) resource name, manage, deploy & monitor. In the coming few

minutes we will talk about each one of them.

APIs Naming & Interfaces

Interface naming is the entry point to your service. It’s the main door where

everyone else can get in. If this door is not obvious and clear, people will lose their

way!

Interface naming is a collection of decisions between developers, designers and

architects and it’s representing the domain, service as well as the required data or

functionality.

Because RESTFul is HTTP based, so you interface must be something like that

https://example.com/users/1234/tasks/2




14

Let’s have few examples on different resource naming to have better idea

GET/POST/PUT https://example.com/users/

Https: is the default protocol for RESTful, however, we added ‘s’ for a secure

connection and will talk about that in security section.

example.com: which refers to an organisation domain, some organisations

have multiple domains based on business functionality.

users: is a resource name, which means we need to get information about

users by calling ‘/users’ resource.

We can’t say if this resource listing all users, create or update a user. This is defined

based on which HTTP method is used and the payload details. E.g.

GET https://example.com/users/ = Get all users

POST https://example.com/users/ = Create new user. User details are sent as JSON

payload into body

PUT https://example.com/users/ = update particular user. User details are sent as

JSON payload into body.

GET https://example.com/users/1234/

Https: is the default protocol for RESTful,

however, we added ‘s’ for a secure

connection and will talk about that in security

section

example.com: which refers to organisation

domain, some organisations have different

domains and this need to be discussed with architects.

users: is a resource name, which means we need to call a /users resource

1234: usually refers to /users unique identifier. E.g. get a user with id : 1234

So this resource means get details for user {id: 1234}. Developer passed path

parameter (/users/{id})

GET https://example.com/users?1234/v1

Response Sample

User: {

Id: 1234,

Name: John,

Phone: 00-000-000

…

}






https://example.com/users?1234



15

This is exactly like above but it’s using Query parameter (‘users?1234’) except it’s

listing the APIs versioning. In case we have an updated version of APIs can’t be

deployed without full test with integrated systems, then versioning is facilitating to

update APIs without downtime.

GET https://example.com/users/1234/tasks/2

Https: is the default protocol for RESTful, however, we added ‘s’ for a secure

connection and will talk about that in security section

example.com: which refers to organisation domain, some organisations have

different domains and this need to be discussed with architects.

users: is a resource name, which means we need to call a /users resource

1234: usually refers to /users unique identifier. E.g. get a user with id : 1234

tasks: usually refers to a relation between users and tasks e.g. get the tasks

for user id :1234

2: is tasks unique identifier

So this resource means get task with {id: 2} for a user {id: 1234}

Based on above explanation, there are three types of parameters

Path Parameter: as part of Interface (/users/{id})

Query Parameter: as part of interface and very old schools (/users?id)

Body: into body which is secure and usually used for sending encrypted data

or large amount of data

NAMING CONVENTIONS:

1- Small letters, don’t use camel case

2- No dashes or special characters

3- Short, concise & meaningful

4- Parameters can be or can’t be part of interface path in case of GET only

5- Versioning is very important for availability

DEVELOPMENT TOOLS




16

Figure 11: https://optimalbi.com

Out of 100s development tool, here are the most common tools.

1. Scripting languages: NodeJS (JavaScript framework)/Python/Ruby/GraphQL

2. Programming Languages: Java/C# & their frameworks (e.g. Spring)

3. Mulesoft which is very powerful and has all-in-one bundle including many

adapters for other systems

4. Oracle Cloud Integration (OCIS) which is Mulesoft competitor but I would

choose Mulesoft over Oracle under many circumstances

5. Oracle SOA/BPM suite which enables exposing SOAP-based developed

services to RESTful APIs

6. TIBCO

7. Webmethods by IBM

Whichever you choose, make sure it fits in business needs and priorities. There is no

such thing as good and bad, but easy and hard, cheap and expensive and it’s all

depends on your organisation needs.



17

APIS TESTING

APIs Testing, is a type of software testing that involves testing application

programming interfaces (APIs) directly and as part of integration testing to

determine if they meet expectations for functionality, reliability, performance, and

securityi.

Since APIs lack a GUI, API testing is performed at the message layerii. API testing is

now considered critical for automating testing because APIs now serve as the

primary interface to application logiciii.

API testing involves testing APIs directly (in isolation) and as part of the end-to-end

transactions exercised during integration testing.

WHY APIS TESTING IS IMPORTANT?

Here are some of the most common reasons people test their APIsiv:

1. Make sure it does what it’s supposed to do.

2. Make sure it can handle the load

3. Find all the way users can mess things up

4. Make sure your APIs work across devices, browsers, and operating systems

5. It can be costly not to

https://en.wikipedia.org/wiki/Software_testing

https://en.wikipedia.org/wiki/Application_programming_interface

https://en.wikipedia.org/wiki/Application_programming_interface

https://en.wikipedia.org/wiki/Integration_testing

https://en.wikipedia.org/wiki/Graphical_user_interface

https://en.wikipedia.org/wiki/Communications_protocol#Layering

https://en.wikipedia.org/wiki/Application_logic



18

APIS TESTING TYPES

There are mainly two types of testing

Automated Testing

Manual Test

Figure 3: Automated Testing Processv

Automated Testing vs Manual Testing

Automated testing requires you to use a

testing tool Manual testing requires you to write your own

code for testing

Automated Testing is used for:

API functional testing

Dynamic testing

Repeated test design

Analysing your functional test

coverage to know what you're

missing

Performance testing

Testing protocols in a single, unified

framework

Data driven testing

Load testing

Error testing

Testing in multiple languages

Regression testing

Manual Testing is used for:

Exploratory testing

Usability testing

Ad-hoc testing

Figure 4: Manual Testing effort vs Automated Testingvi

https://www.soapui.org/docs/functional-testing/getting-started.html

https://www.soapui.org/docs/data-driven-tests/functional-tests.html

https://www.soapui.org/load-testing/concept.html



19

Automating testing Toolsvii:

Postman

HttpMaster Express.

RoboHydra Server.

Hippie-Swagger.

WebInject

Karate DSL.

Rest- Assured.

PyRestTest

AirBorne

Unirest

SoapUI.

Rest Console.

Mockbin

Citrus Framework

And one of the best now is

API Fortress

Figure 5: http://www.resanehlab.com

http://apifortress.com/



20

TESTING TYPES BY FUNCTIONALITY

Functionality testing — the API works and does exactly what it’s supposed to

do.

Reliability testing — the API can be consistently connected to and lead to

consistent results

Load testing — the API can handle a large amount of calls

Creativity testing — the API can handle being used in different ways.

Security testing (Penetration test) — the API has defined security

requirements including authentication, permissions and access controls. See

some API security tips for protecting vital data

Proficiency testing — the API increases what developers are able to do.

API documentation testing — also called discovery testing, the API

documentation easily guides the user.

Fuzzing & Sanitization (Negative Testing) — checking for every kind of wrong

input the user can possibly supply

Scheme Validation — checking that request/response are following the

canonical model by validating it against predefined scheme.

The kinds of tests you will run will vary, but these are common API test examples, as

you can see, they are very similar to the reasons why you would want to test your

API:

o Checking API return values based on the input condition

o Verifying if the API doesn’t return anything at all or the wrong results

o Verifying if the API triggers some other event or calls another API

o Verifying if the API is updating any data structures.

TESTING PHASE PREPARATION

The first part of API testing involves setting up a testing environment, with the

required set of parameters around the API. This involves configuring the database

and server for the application’s requirementsiv.

Once you have your environment ready, then you need a test cases which is list of

steps requires to verify different scenarios.

To create test cases, ask yourself the following questionsiv:

Who is your target audience? Who is your API consumer?

What environment/s should the API typically be used?

https://www.soapui.org/professional/soapui-pro.html

https://www.soapui.org/testing-dojo/best-practices/scenario-based-testing.html

https://www.soapui.org/professional/loadui-pro.html



21

What aspects are you testing?

What problems are we testing for?

What are your priorities to test?

What is supposed to happen in normal circumstances?

What could potentially happen in abnormal circumstances?

What is defined as a Pass or a Fail? What data is the desired output? What is

the chain of events?

What other APIs could this API interact with?

Who on your team is in charge of testing what?



22

APIS DEPLOYMENT

To enable users to call your APIs, it has to be deployed to a server and get exposed

to the internet.

To deploy APIs to backend server, you have to be aware of deployment general

concepts.

Deployment General Concepts

This following acronyms are not similar for all products, but the same concept is

followed everywhere:

APIs is the real code you have developed.

Gateway Nodes is a physical backend server hosts the APIs.

Gateway is a logical grouping of server nodes.

DEPLOYMENT SERVER TYPES

When it comes to infrastructure servers/hosts, there are mainly 5 types:

1. On-premises Server, which is just a normal servers resides in your

office/datacentre

2. Cloud Server, which is just a server but on cloud service (AWS, Google, Azure,

Oracle)

3. Virtual machines, which is a virtual machine created using installed software

on Cloud/On-premise servers

4. Containers, which is lighter version of virtual machines

VMs take up a lot of system resources. Each VM runs not just a full

copy of an operating system, but a virtual copy of all the hardware that

the operating system needs to run. This quickly adds up to a lot of RAM

and CPU cycles. In contrast, all that a container requires is enough of

an operating system, supporting programs and libraries, and system

resources to run a specific program.

5. Serverless, which is actually managed server on cloud and its self-automated

managed. So servers are not your responsibility. Deployed APIs to Serverless

framework called (Faas – Function as a services)

Whichever you use, they are all just servers with operating system and software

installed on top of it.



23

APIS MANAGEMENT

Role: API Managers

Once APIs are developed and ready to face the external world, this is the right time

for APIs gateway. Just pre-delivery.

APIs can’t get exposed directly to the public internet without setting a lot of

configuration required to maintain the flexibility, high availability, security and more

of configurations which keep your APIs up and running smoothly and successfully

without failure or downtime.

In this phase we will take about the API gateways they are the main gate to your

APIs.

BUT THE QUESTION IS WHY?

Public internet is very risky area, it’s a red zone for APIs. Red zone is where we have

Viruses/Malwares

DDos attacking

Man-in-the-middle attacking

XML/SQL/LDAP injections

…and much more high risks are invented every day.

Well! APIs gateways will not protect your physical environment however, they will

keep your APIs safe as much as they can. For example, they will protect you from all

kind of injections and attacking which is very important!

In security section we will talk more about what each one of them is and how to

protect your physical environment.

For time being, you need to know that APIs gateways act as a firewall to your APIs

and verify logged in users, stop attacks and injections.



24

Figure 12: https://blog.akana.com/2016-predictions-api-management/

Different APIs gateways solutions provide different sets of features, but let’s explore

some of the most common features

SECURITY

Basic Authentication, in which we have only a username/password to allow

API access

OAuth, this is very common SSO framework. It’s allowing Single Sign on

authentication like SAML. So user can authenticate using Facebook account,

google account, etc. (OAuth vs SAML)

Key Validation, this is a different form of authenticating users using

keys/certificates which is the most secure way nowadays. (Cryptography-key)

IP Filter Validation, in which API manager can set list of Whitelisted and

Blacklisted APIs to allow IP and block others.

CORS, this is very common to access APIs from different domains. (CORS)

Brute force attack, this is when attackers generate random passwords and

keep testing it against your APIs. (Brute-Force)

Privileges, where APIs manager will be able to grant user’s permission to

access the APIs.

Proxy, some solutions provide a way to configure a proxy in front of your APIs

which acts again as second firewall layer.

https://www.ubisecure.com/uncategorized/difference-between-saml-and-oauth/

https://en.wikipedia.org/wiki/Public-key_cryptography

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

https://en.wikipedia.org/wiki/Brute-force_attack



25

THROTTLING & LIMITING

Throttling, controls the global volume of requests to you APIs.

(e.g. if you want your API to receive only 100 requests per a second, all

requests coming above 100 will be delayed with a pre-configured amount of

time e.g. 2 sec). This will guarantee the 24 hours availability and prevent

Dos/DDos attack in which attackers send tons of requests to get server down.

API Rate limiting, this is another option of limiting number of requests per

amount of time – e.g. 100 request / per hour). Amount of time can be

minutes, hours or days, weeks or months. Once limit reached, APIs will not be

available. There are different types of rate limiting by user, server or region.

Application Rate limiting, some gateways like Oracle platform organising APIs

by grouping them into applications and that’s where you can limit amount of

requests from an application to APIs.

VALIDATION & MAPPING (INTERFACE MANAGEMENT)

Interface filtering, is a way of filtering (pass/reject) request based on resource

URI & method. (e.g. (Pass => /domain.com/users/cars)

Resource Mapping, is very powerful feature to encapsulate your APIs details

by providing different /resources, query parameters to customer and then

add your mapping before request including setting header and form fields.

Header Validation, is a very important feature to filter (Pass/reject) requests

based on presence values in header

Fields Encapsulation/Redaction, is another opportunity for header/payload

data encapsulation to show list of fields but not others.

ROUTING

APIs Managers can add routing configuration based on Header, Application, etc.

This is sort of mapping to your APIs based on request details to encapsulate your

real APIs.

DEPLOYMENT & PUBLISHING

API managers can deploy the developed APIs to backend servers and publish them

to developer portal.

LOGGING & MONITORING



26

This is a mandatory as we can’t speak about APIs security without having logging

and monitoring tool. API Gateways provide different types of loggers and built-in

graphs. For example:

Number of hits / time

Payload size

Response time

… And more of reports which are not similar for all products

APIS GATEWAYS SOLUTIONS

Figure 13: https://azure.microsoft.com/en-us/services/api-management/

Not all APIs gateways are the same. Providers are following specifications adding

their competitive advantage, but they are all same in providing a full bundle to

document, developer, deploy, secure, publish & discover APIs and that’s why they

called APIs Managers.



27

APIs gateways products

Mulesoft API Manager

Oracle API Platform

Tyk API Manager

Apigee

Nginx API gateway

Amazon API Gateway

CA API Manager

Google API manager

Microsoft API Manager

IBM Websphere API Manager

There are few comparisons available on internet, but I believe if you need to choose

you have to go through each of them and test their functionality against business

needs and cost. We will talk more about how to choose the right product based on

some factors in coming section however, the following links will help you to have a

better idea in how to compare them

Mulesoft vs Oracle API platform

Oracle API Platform vs Apigee

Tyk vs Apigee

Amazon API Gateway vs Mulesoft API Gateway

https://www.mulesoft.com/platform/api/manager

https://cloud.oracle.com/api-platform

https://tyk.io/

https://apigee.com/

https://www.nginx.com/solutions/api-gateway/

https://aws.amazon.com/api-gateway/?sc_channel=PS&sc_campaign=acquisition_NZ&sc_publisher=google&sc_medium=api_gateway_b&sc_content=api_gateway_e&sc_detail=amazon%20api%20gateway&sc_category=api_gateway&sc_segment=161188304089&sc_matchtype=e&sc_country=NZ&s_kwcid=AL!4422!3!161188304089!e!!g!!amazon%20api%20gateway&ef_id=WqXXVQAABBA5SytQ:20180312012645:s

https://www.ca.com/us/why-ca/api-management.html?intcmp=headernav

https://console.cloud.google.com/home/dashboard?project=plasma-iterator-165801

https://azure.microsoft.com/en-us/services/api-management/

https://www.ibm.com/support/knowledgecenter/en/SSWHYP_4.0.0/com.ibm.apimgmt.overview.doc/api_management_overview.html

https://www.itcentralstation.com/products/comparisons/mulesoft-anypoint-api-manager_vs_oracle-api-management

https://www.itcentralstation.com/products/comparisons/apigee_vs_oracle-api-management

https://www.itcentralstation.com/products/comparisons/apigee_vs_tyk

https://www.gartner.com/reviews/market/full-life-cycle-api-management/compare/amazon-web-services-vs-mulesoft



28

APIS PUBLISHING, DISCOVERY & CONSUMING

Yet another important feature by APIs manager which is publishing your APIs to a developer

portal where allowed users can login, create applications, subscribe to APIs, read

documentation and know more about APIs interfaces, Input/output payloads.

API DISCOVERY & CONSUMING

Once APIs manager deploy APIs and publish them to a developer portal and set user access,

developers can login to developer portal to consume it

Discover APIs, is to be able to list all APIs you have an access to and be able to have an

access to APIs documentation to know more about how to consume them by calling a

particular end point (interface name), sending pre-defined input scheme, expecting a

pre-defined output scheme.

Consuming APIs, once you have the APIs available you can create an application to

subscribe to a particular APIs. Applications are logical grouping of APIs subscription and

can be configured as web app, mobile app, etc.

Below photo is a sample of Trello portal developer.

Figure 6: Trello Developer Portal



29

APIS DEVELOPMENT FAQS

WHAT COMES FIRST, DESIGN OR DEVELOPMENT?

Answer: actually there is no clear answer for this question. Different developers,

different schools.

There are two ways to develop APIs:

1- Design First: The plan is converted to a human and machine readable

contract, such as a Swagger document, from which the code is built

2- Code First: Based on the business plan, API is directly coded, from which a

human or machine readable document, such as a Swagger document can be

generated

So you are free to choose, however, both are mandatory.

HOW TO CHOOSE THE RIGHT PRODUCT?

Choosing the right product for your business needs can be tough and there is no

point in choosing one for you if they are all competitors and can do the job.

However there are many factors will help you to make a decision:

Business needs against Gateway features, it’s pointless to use multiple

products to do one functionality unless there is a critical bug in this product

could harm your business (e.g. security issue).

Licensing and cost is another important factor in your choice. Cost is always

calculated against revenue & benefits you will gain (e.g. consistent service,

great support, high flexibility and secure environment)

Customer reviews are the most important, considering the rank, popularity

and customer experience you will have a better vision about the product

Easiness of service setup and deployment. This includes maintenance and

replacement in case of failure you might face.

The urgency of delivery against quality & performance.



30

HOW TO ASSESS THE COST?

Assessing the APIs cost depends on multiple factors:

1- First you need to define the business requirements

2- Applied Security limitations into an organization and what is allowed for you.

For example, while Serverless doesn’t give you an access to your servers, you

can have this access with containers.

3- Traffic is very important factor in cost assessment (e.g.

a. how many concurrent users do you have in your system

b. how many APIs are available

c. the concurrent request on each APIs (e.g. AWS Serverless limits

concurrent request to a particular resource to 1000, but you can ask

more)

4- What technology is used and what kind of servers are required (e.g.

a. Oracle Service Bus is much more expensive than NodeJS, but it’s easier

to integrate with different products like Salesforce, MQ. So it’s totally

depends on your business.

5- In addition to multiple factors like

a. How many developers do you have

b. Developer rate per hour

WHO IS USING APIS?

Nowadays, everyone is using APIs and the largest solutions in the world are APIs based, e.g.

Amazon Webservices

Netflix

eBay

Mulesoft – developed by APIs for APIs

Google

Facebook

Everyone likes to start business now, use APIs

Airbnb

Trello

Apiary

Api fortress



31

APIS REVENUE MODELS

APIS MONETARIZATION

The purpose of developing APIs is not only systems integration, but there are few

revenue models can be a trigger to develop APIs.

Develop complete solution based on APIs (e.g. Trello, AWS)

APIs-based solution can expose their APIs to be used by other solutions (e.g.

Google APIs, Trello APIs)

Providing a functioning APIs to your client by exposing backend systems to be

consumed in different apps (e.g. mobile application, integration )

integration which was the trigger for APIs inventions

And more…

APIs Monetarization is the common name for different APIs revenue models.

Out of 10s of APIs models, the most popular ones are

1- Charge Directly for an API, by Call or Subscription: charge customer per call

2- Improve Operational Efficiency and Decrease Time to Market

3- Drive Revenue-Generating Activities Through Your API

For more information and models visit the following links:

1. Top 5 API Monetization Models | API Business Models

2. Monetization: Unlock More Value from Your APIs

3. Direct & Indirect Monetization

4. Monetizing use cases

https://nordicapis.com/top-5-api-monetization-business-models/

https://apigee.com/about/blog/api-technology/monetization-unlock-more-value-your-apis

https://www.quora.com/What-are-innovative-ways-to-monetize-your-API

https://www.ca.com/content/dam/ca/us/files/ebook/api-monetization-unlocking-the-value-of-your-data.pdf



32

APIS SECURITY

API SECURITY

As the world around us becomes more and more connected via internet

connections, the need to build secure networks grows infinitely. APIs continue to be

an integral business strategy across industries, and it doesn’t appear to be slowing

down anytime soon, especially with the rise of IoT.

Adding to that the cloud now is the main infrastructure for most of systems in which

all systems are exposed directly to public internet by default.

Security is not just setting a username/password to your APIs, but securing the

whole environment including servers and people they are working on it.

Security specialists organisations provided us with a set of compliances and policies

must be in place to deliver a secure system. They called it ‘Security Controls’. It’s

providing ‘defence-in-depth’ security which is applying multiple security layers.

Security controls are set of

Compliances and Policies

Procedures to be followed to setup correct policy

For example, to be able to use Credit payment you have to follow ‘PCI DSS’ for

secure payment system.

Security controls are grouped into three categories.

Physical, which is related to hardware and network components

Technical, in technical we will discuss more about securing APIs and software

Administrative, it’s more about securing people

This is also known as (defence-in-depth) which means to apply multiple security

layers.

Security Controls guarantee system security by applying the following concepts:



33

Confidentially, it’s to guarantee that confidential data will not go to wrong

person and it will go to right person. It’s how to authorise right people to get

the right data

Integrity, it’s a data consistency over the life cycle. It’s to guarantee that data

will not be altered or changed in transit or during any of its life cycle.

Availability, it’s to guarantee the availability of APIs 24/7 and this includes the

hardware and software as well.

Auditing/Accountability, that fact of setting responsibility expectations and

who is responsible for what. Hence auditing is quite important for every

single action in case of risk response and forensics.

WHERE SECURITY CONTROLS ARE COMING FROM?

AUTHENTICATION & AUTHORISATION

Authentication is authenticating the user against resource while Authorisation takes

after what permissions are granted to an authenticated user.

In other words, your smart card is your authenticator to the office, while using

laptop is what you are authorised for. Again, login to windows is an authentication

process while printing papers is what you are authorised for.

Authentication

Authentication is based on one user’s property

Something user have (e.g. Smart card)

Something user know (e.g. authenticator, password)

Something about user (e.g. finger print, voice recognition)

Somewhere user are (e.g. authenticate user only from particular region)

Security Governance

Security Controls

Policies & Compliances

Procedures

Standards

Laws & Regulations

Best practicies

Common sense

Policies

Security Controls Examples

- Acceptance user Policy

- Data classification policy

- Equipment usage policy

- Personnel policy

- Privacy policy



34

Federated authentication

Unless APIs are public, you need to set one of authentication methods

There are multiple authentication methods

Basic Authentication, in which developer can access resource/ API using only

a username/password. Which is {insecure} because password is easily

hackable using any of attacking method (e.g. Brute-force, dictionary attack).

Federated/SSO authentication, in which you can allow developers to login

using

a. SAML using identity provider (e.g. Facebook, Google, …)

b. Authentication server (e.g. OAuth)

And it’s very {Secure}, unless developers get hacked and attackers used their

Facebook or google credentials to login to your system and use your APIs.

IP filtering, this is another important point to limit user access by IPs. So if you

are sure about who are using your APIs and what network is used for sending

requests, then you can filter coming requests by IP. This can be done in

different ways e.g.

- APIs Gateways, is a built in feature to list White/black listed IPs

- NACL, Network access control list where you limit access to the

machine based on IP

CORS, which is very important to stop cross scripting attack from different

domains.

Digital certificate, the most secure way for APIs is to setup a signed certificate

for your APIs (e.g. VeriSign certificate).

- You can create your own certificate, but signed certificated via third

parties are more trusted and secured.

Finally, you can grant everyone an access to your APIs but the most important how

are they going to use it. That’s why we need proper authorisation takes place.

Authorisation

Permissions

Rights

Authentication is done on two levels



35

APIs Consumers / Users

APIs developers

The golden rule in setting up right authorisation for all levels is to

grant users the least privileges

separate duties

don’t share accounts between users

continuous monitoring with alerts

use different groups to categorise people

put complex password rules

- No default passwords

- Set complexity level (e.g. #AaBb342)

- Track history of passwords (e.g. don’t allow a password used in last 5

times )

- Change password periodically (e.g. every 90 days)

Forcing password rules will guarantee applying other rules, like not to use shared

accounts and duty separation.

General rule, APIs must exposed over HTTPS protocol only, not HTTP.

INFRASTRUCTURE HARDENING

Unless you are using one of managed services (e.g. AWS lambda – Serverless), then

you are require make sure that you have a very secure infrastructure including

network and servers in which you will do the best to filter and catch bad requests

before getting submitted to your APIs.

We call that ‘defence-in-depth’ or ‘security layered’ which means installing multiple

defence layers before the request hitting your APIs.

There are multiple risks threat your infrastructure, it could be

Adversarial as a malware.

Accidental as a user/developer mistake, awareness less.

Environmental as flooding.

Structural as a physical damage.



36

In the following section we will discuss each of them in details and how to get rid of

them! In addition to the risk management section in which we will discuss how to

manage risks and different types of risk response.

DATA, HOST & NETWORK SECURITY

There are different possibilities of how your Network/host getting harmed. It could

be a malware, direct attack or physical damage.

PHYSICAL DAMAGE

Physical damage is just a damage happened to your hard disk, mother board or a

router. In this case you need to replace the broken device/piece considering the risk

assessment procedure which is discussed below.

MALWARES

Malwares, Malwares have different shapes, it can be:

A virus, which gets propagated and activated immediately

Adware, which is a software targeting revenue by setting up online

advertisements

Spyware, which is spying program get installed to your machine and capture

a lot of important information (e.g. credit details, login credentials, etc.)

Ransomware, which is locking your machine before compromising your with

money.

Torjan horse, which is hidden into software and gets activated once you

install a software. It’s creating a backdoor into your machine possibly allowing

personal and confidential information to be compromised.

Remote Torjan horse, is another form of torjan, but it gets activated remotely

which attackers decide to activate it.

Polymorphic malware, which is changing the way it looks on computer to

avoid getting captured by anti-malwares. This very dangerous.

Armored virus, yet another form of virus change it’s binary to disallow reverse

engineer so you never find anti-virus

Logic bomb, which can be installed on network and getting triggered based

on event (e.g. delete an employee account after getting fired)

How to get rid of Malware?



37

Well! Make sure the antivirus is not only installed into your machines, but

The whole network must be protected with Anti-virus / Anti-malwares they

getting updated periodically. Don’t allow people connected to the network to

close it. It must be administrated by an administrator only

Continuous monitoring is quite important for users behaviours

Set strict equipment usage policy and don’t allow USBs to get into machines

Don’t allow strangers to connect their laptops to your network.

Don’t use default username/password on network router, switches, machines

or anything else.

ATTACKS

There are hundred types of attacks are there, but we will discuss only the most

critical and important ones.

DENIAL OF SERVICE

In this type of attack, attackers try to get servers down by sending a lot of

packets in small periods.

There are three types of DOS:

1. Volumetric attack, in which they will use TCMP/UDP protocols to run ping

command or sending UDP packets and overflow server with requests.

2. Protocol Attack, in which they use TCP/IP shake hand method and overflow

server with SYN packets to get down.

3. Application Attack, part of this attack is Smurf Attack in which attackers are

using DDos (Distributed Denial of Service). This means attackers are using

multiple machines to hit the application and overflow it with requests until it

gets down.

How to get rid of DDOS?

1. API manager’s platform allows you to

- Set throttling to APIs in a particular period and delay the exceeded

amount of requests.

- Set Rate limiting by user, servers and regions which limiting the

amount of hits to your APIs



38

2. Continuous Monitoring is very important again; by monitoring network

bandwidth and number of hits on different APIs, you will notice strange

behaviours from some IPs. That’s when you can put this IP into blacklist. This

can be done on NACL & API manager. Review authentication section.

3. If you have limited subscriber in pre-defined networks, it’s preferred to setup

a whitelist/blacklist into NACL and API managers. Review authentication

section.

MAN IN THE MIDDLE

Another risk can harm your APIs confidentiality & Integrity by interrupting

connection, access in transit data and alter it.

How to get rid of Man in the middle?

4. Apply in-transit data policies procedures

5. APIs manager allow configuration to prevent Man in the middle attack.

USER’S IGNORANCE

Yet another very risky attack your servers are exposed to which is people

ignorance.

6. Spam, in which developer can click a link on lottery email

7. Spim, another form of Spam over instant messages

8. Phishing, imagine you receive an email from very famous company asking

you for your salary because they have a job offer for you

9. Spear phishing, imagine this email is coming from taxes services including

information about you asking about your bank account details for some

transactions.

10. Vishing, another form on phishing over phone.

11. Type squatting/ domain hijacking, imagine you have types gooogle.com so

you get redirected to similar homepage with a button to install spyware to

your machine.

How to get rid of User’s ignorance?



39

Part of securing your environment is to train people well and expose them to

different security use cases, this doesn’t mean to skip monitoring, but it will

provide better protection for your environment.



40

DATA SECURITY

There are few procedures to guarantee confidentiality, availability, integrity &

accountability for local and In-transit data

LOCAL DATA

Local data is the data resides on your computer and out of different data protection

methods, I would choose Disk Encryption & RAID for data protection.

Disk Encryption, is a technology which protects information by converting it into

unreadable format that cannot be deciphered easily by unauthorized people. There

are different hardware & software tools for disk encryption (e.g. File Vault for non-

windows systems, BitLocker for windows systems).

RAID, is a data storage virtualization technology that combines multiple physical disk

drive components into one or more logical units for the purposes of data redundancy,

performance improvement, or both.

IN-TRANSIT DATA

In-transit data is the data travel between services/devices over the network or

public internet which is more exposed to risks and attacking (e.g. Man-in-the-middle

attack).

To protect in-transit data, either we use a secure network transfer method e.g.

SAN/NAS or encrypt data which is cheaper and more secure method for time being.

NAS/SAN, are a high speed networks that provide a secure and quick transfer for

data over network. Both are good, however NAS is file level & cheaper while SAN is

block level and more expensive.

Cryptography, is about hashing/encrypting your data

To guarantee data integrity and avoid attacks such as Man-in-the-middle attack in

which attackers try to get in-transit data and alter it, then data has to be encrypted

while it’s moving over the local area network or the public internet.



41

The good thing about cryptography, it’s free and there few options can be used for

encryption e.g. MD5, SHA-1 & SHA-2. However, the latest is the most secure. While

MD5 & SHA-1 are having collision attack issue. SHA-2 is difficult to be guessed or

hacked.

There are two versions of SHA-2

SHA-256

SHA-512

HMAC is another option to hash in-transit data and it’s highly recommended for

more secure results. It’s more complex and provides hashing using one of above

algorithms in addition to secret cryptographic key.

The basic idea is to concatenate the key and the message, and hash them together.

Since it is impossible, given a cryptographic hash, to find out what it is the hash of,

knowing the hash (or even a collection of such hashes) does not make it possible to

find the key. E.g.

HMAC = SHA-256 (data + Secret cryptography key)

Adding a key to your hashing makes it stronger and more complex to be hacked

unless users machines get hacked and the key is used by fake users, even though

still you have hashing in place.

A Collision attack on a cryptographic

hash tries to find two inputs producing the

same hash value

Wikipedia

Figure 7: Collision Attack - https://www.howtogeek.com/

https://en.wikipedia.org/wiki/Cryptographic_hash

https://en.wikipedia.org/wiki/Cryptographic_hash

https://en.wikipedia.org/wiki/Collision_attack



42

https://www.networkworld.com/article/2268575/lan-wan/chapter-2--ssl-vpn-technology.html



43



44

DATA/HOST/NETWORK SECURITY TIPS

Is that all? Of course, Not! Attackers will never stop attack you with all different

possibilities, then you have to be ready!

Furthermore, you need to make sure of having a very secure environment by

implementing the following steps:

1. Disable all un-necessary services

2. Disable all un-necessary users

3. Train people and keep monitoring them.

4. Patch management, never mess updates for any of network equipment’s.

These updates usually fix bugs and closing gaps, backdoors into your

machine. But before you put the patch, you need to

- Keep monitoring network equipment’s newsletter in case any of them

have a patch.

- Evaluate whether it’s important for you

- Test patch on pre-production environment

- Deploy patch to your production environment

- Document your equipment updates.

5. NACL, Network access control list. By default everything is denied and we

have to allow connections if we need to get access to our machine/network.

Make sure to allow only connections from particular source (IPs) on particular

port.

- E.g. don’t allow SSH on public internet. Only allow SSH (22) from local

machines

- E.g. only https (443) for machines accessible to internet

6. Use multi-factor authentication to login to your systems. In which users have

a generated password every (e.g. 30 seconds) into mobile app or sent SMS

7. Configure strong & strict firewall rules in which you can

- Allow an access to a particular port on machine, however, you can’t

allow/deny using IP. This is the second defence layer after NACL.

8. Grant only least privilege for users.

9. Vulnerabilities scanner, there are many tools will help you to scan your

network against vulnerabilities



45

10. API manager again will play a role in

- Stopping XML/SQL injections

- Sanitizing

- Validate client requests and authenticate it

- Cross site scripting

11. Test your APIs against Buffer/Integer Overflow for availability.

12. Always use secured services (e.g. FTPS, TLS, SMTP, etc)

13. Install IDS/IPS (Intrusion detection system/Intrusion prevention now), is a

device or software application that monitors a network or systems for

malicious activity or policy violations. It can be part of firewall or separate

device/software.

Are of deception

You can do all protection procedures and forget about your bad

employees/colleagues. You never know!

1. Make sure on premise datacentre door is well closed and not authorised to

anybody to enter this room.

2. Make sure not to leave the screen unlocked while you are away from your

desk.

3. If you are working on cloud, so you are fine, but still has to make sure SSH is

not accessible by letting open connection into your unlocked screen.

4. Avoid shoulder spoofing in which your colleges can try to have a look to your

screen over your shoulders.

Those rules are not only for your laptop/servers, but for every equipment in your

infrastructure and must be followed by all employees.

HIGH AVAILABILITY

High availability is very important factor in security. It’s how to guarantee your

system availability and avoid the downtime.

There are two points to consider:

5. Development time

6. Runtime



46

Development time

During development you might need to release a new version of your APIs, make

sure to design your APIs in a way that enable periodic deployment without

downtime. This includes APIs versioning.

Pre-Production environment is very important to test your release against before

moving it to production to avoid any failure. This implies testing the new version of

APIs with old integration instances.

Runtime

During runtime, you might face any of discussed attacks or an unexpected load

getting your servers down.

Hence, it’s important to have an environment backup in case we lost the first one.

The concept of having multiple environments to serve clients called ‘Clustered

environment’

CLUSTER VS LOAD BALANCER

Clustered environment is active-passive model. Active-passive means you have two

machines or two groups of machines but 1 machine is active and services

customers while the other one is idle until first machine goes down.

Load balancer is Active-active model. Active-active exactly the same as above except

both machines are working together to serve the customers which is more secure.

Load balancer distributes the requests between two machines which means none

of them will go down.

Unless, we have an unexpected traffic, load balancer will maintain the availability by

distributing the requests, but if we had an unexpected traffic then it’s time for auto

scaling function.

AUTO SCALING

It’s very easy now to setup ‘Automatic Scale’ feature on cloud environment which

upgrade and downgrade your infrastructure by propagating/terminating instances

of your server based on two inputs:

1. a snapshot of your servers



47

2. Load configuration template (e.g. if servers are 70% loaded, then propagate

two more instances)

Another option to setup auto scaling on your premises or even on cloud is to

automate the environment.

Automating the environment means to use one of automated tools to propagate a

new environment by writing a procedure using infrastructure scripting code.

Automating tools:

1. CHEF

2. Puppet

3. Jenkins



48

LOGGING & MONITORING,

Logging and monitoring is very important for your security.

Logging doesn’t stop on your APIs, but logs must be everywhere

There are two types of logging:

1. Auditing log [user-based], which logs all users’ behaviours.

2. Functional logs [system-based], which logs all systems behaviours.

Both logs must be well defined, organised, written in a clear format. There many

tools will help you log on cloud (e.g. AWS provides AuditTrail & CloudWatch) they are

providing a very clear and clean format in addition to filtering options. However,

even without cloud services logs must be configured well into your APIs for

supporting and trace & investigations.

Digital Forensics

If we consider attacks are crime, attacker is a guilty then we need to open an

investigation. This is called ‘Digital Forensics’ which is investigating into a crime to

capture the guilty person’s details and catch them. Without logs, you will never get

something.

In addition to API manager’s loggers and monitors tools, we need to configure

monitor alerts and notification everywhere. There are many tool will help you to

capture and set alerts based on log events. (E.g. AWS cloud watch is very powerful

tool to have clean, clear logs as well as setup alerts and notification based on

events.)



49

RISK MANAGEMENT

This is another big story, but because we are talking about security so we must discuss at least

the basics of risk and how to assess and response.

Risk is not only a virus or malware detected in your machine, but it could be server, router,

operating system, datacentre, etc.

To asses a risk you need to work with 5 definitions

Asset, which is the infected item. (e.g. router)

Vulnerabilities, are what is the threat I have for this asset (e.g. backdoor bug into a

webserver)

Threat, the real risk after it took a place (e.g. someone attacked my machine, router gets

broken already)

Likelihood, how many time likely to have the same issue again

- Qualitative (e.g. how this risk will affect my quality – client work)

- Quantitative impact on my work (e.g. amount of routers I have against how much

will pay to get another one)

Impact, what is the impact?

- Qualitative (e.g. how this risk affected my customers?)

- Quantitative (e.g. how this risk affected my environment?)

Risk management is separate to two phases:

1. Risk Assessment

2. Risk Response

RISK ASSESSMENT

In risk assessment we will use Asset value to calculate or loss expenses in a year.

Let’s take a broken router as use case.

Asset value, which is

- The price of asset. (e.g. router price = 3500 USD) +

- The price of fixing it (e.g. 0 USD) +

- The price of engineer will setup it (e.g. 10/hr => 4 full working days = 10

* 8 * 4 = 320)

- The price of failure we have for (5 days = 40 * 5 = 200 USD)

- Then the total ASSET Value = 3500 + 320 + 200 = 4020 USD

EF (Exposure factor), potential percentage of loss to a specific asset (e.g. 50%)



50

SLE (Single Loss Expenses) = ASSET Value * Exposure Factor = 4020 * 0.50 =

2010

ARO (Annual rate occurrence), what is rate of annual occurrence (e.g. once a

year)

ALE (Annual Loss Expenses), ARO * SLE = 1 * 2010 = 2010 USD

Then final financial risk per year = 2010 USD/year.

- This can be a flood you experience twice a year and cause damage to multiple

Servers

- Air conditioning broken once each 5 a year

Risks are grouped into 4 categories

Adversarial (e.g. adware, virus, …)

Environmental (e.g. Air Condition, fire, earthquake, flood, …)

structural (e.g. Physical break, broken router, damaged hard, …)

Accidental (e.g. human error, user wrote something to database caused it to

corrupt, …)

RISK RESPONSE / MITIGATION

The first step in risk response is the most important step and can save lives.

However, responding to a risk depends on what the risk is, e.g.

If risk is a virus, then machine has to get disconnected immediately from the

network.

If risk is a router, then it has to be replaced immediately if it’s single-point—

of-failure.

If risk is a flood, then machines have to be disconnected immediately.

While some people categorise it into 4 types, I would say Risk response has five

types:

Risk Mitigation, it is about dealing with the risk. If it’s a virus, then clean the

hard disk, if something damaged then fix it.

Risk Interference, which is to handover it to third party to take care after it

Risk Acceptance: Risk acceptance does not reduce any effects however it is

still considered a strategy. This strategy is a common option when the cost of



51

other risk management options such as avoidance or limitation may

outweigh the cost of the risk itself.

Risk avoidance is the opposite of risk acceptance. It is the action that avoids

any exposure to the risk whatsoever. Risk avoidance is usually the most

expensive of all risk mitigation options.

Risk Limitation: Risk limitation is the most common risk management strategy

used by businesses. This strategy limits a company’s exposure by taking some

action



52

REFERENCES i Testing APIs protects applications and reputations, by Amy Reichert, SearchSoftwareQuality March 2015 ii All About API Testing: An Interview with Jonathan Cooper, by Cameron Philipp-Edmonds, Stickyminds August 19, 2014 iii https://en.wikipedia.org/wiki/API_testing iv https://www.soapui.org/testing-dojo/world-of-api-testing/api-testing-101.html v https://medium.com/aubergine-solutions/android-automated-testing-with-jenkins-and-firebase-158015173703

vi https://www.pwc.com/us/en/industries/financial-services/library/viewpoints/software-failure-automated-functional-testing.html vii https://www.joecolantonio.com/2017/05/16/12-open-source-api-testing-tools-rest-soap-services/

http://searchsoftwarequality.techtarget.com/tip/Testing-APIs-protects-applications-and-reputations

http://www.stickyminds.com/interview/all-about-api-testing-interview-jonathan-cooper

https://en.wikipedia.org/wiki/API_testing

Documents

apis from idea to market - amrsalah.techamrsalah.tech/mwcwp/wp-content/uploads/2018/03/APIs-from-IDEA-to... · Backend services ... SWAGGER, RAML) APIS FOR DEVELOPER & ARCHITECTS