P1 Examine the relationship between an API and a software development kit (SDK)

What is an API?
Broadly speaking, an Application Programming Interface (API) is a set of
subroutine definitions, communication protocols, and tools for building software. In
general terms, it is a set of clearly defined methods of communication among various
components.
 
There are two main types of APIs, server-to-server or client-to-server, and component-
to-component. Server-to-server and client-to-server APIs are commonly a stateless
interface to a remote server to set  or get  data. Typically, these types of APIs use
a “RESTful” (representational state) protocol which requires them to
be “stateless”. Stateless protocols require that any call to the API be completely
independent from any past or future calls to the API. The API defines a
communication protocol and “expected behavior” that allows a client to make requests
and receive responses to and from a server. It is the developer's responsibility to
integrate an API into their solution and use the API correctly. Component-to-
component APIs can act a bit differently. These APIs allow different software
packages to communicate on the same device and are not communicating with an
external server or device. A good example of this would be Android’s set of APIs.
 
APIs work on all operating systems and are commonly used on IoT devices and for
device tracking & management platforms. This makes them a great solution for
customers that use proprietary operating systems and protocols as well as end-to-end
vertical solution providers.
 
Skyhook offers an API as one of four flexible integration options to access its
Precision Location software. When utilizing this location API, the developer is
required to source the Wi-Fi, GPS, and cellular data, and then implement the API
request according the the specifications outlined.
 
What is an SDK?
A Software Development Kit (SDK) is commonly defined as a set of tools that can be
used to create and develop applications. In general, an SDK refers to a full-suite
software module that includes everything developers need for a specific module within
an app. They are often compared to a code library, which is a collection of non-
volatile resources, used by computer programs, often for software development. They
often “wrap” (fully or partially implement) an API and utilize the API’s
communication protocols in the appropriate and intended manner. They include
examples, documentation and, the methodology necessary to perform specific
functions.
 
For example, Skyhook’s Precision Location SDK provides all the tools and
documentation needed to perform highly accurate geo-positioning on a mobile device
using the Android operating system. The app developer simply needs to load, or
dynamically pull, the SDK library into their development environment and use the
available interfaces to utilize all the capabilities Skyhook provides. No extra code is
needed to source the Wi-Fi, GPS, or cellular data to calculate an accurate position -
this is all handled by the SDK.
 
Additional benefits of Skyhook’s SDK include location smoothing, a fast time-to-fix,
MAC address collapsing, stationary detection, offline location, and power
optimization. See how each of these features can add value to connected devices:

 Location Smoothing – Algorithms that use historic location data and patterns to
inform device locations in the future.
 MAC Address Collapsing – Intelligent filtering to detect multiple MAC
addresses associated with one router. This helps evenly weight all access points
used for location, without creating a bias towards a particular access point.
 Stationary Detection – Patented method for determining if a connected device
is stationary, through measuring the Doppler frequency of received satellite
signals.
 Offline Location – Determine device location, even when offline, by collecting
a token that gets replayed once devices are back online.
 Power Optimization – Technology to minimize the number of access points that
need to be scanned to yield accurate location results and reducing the time it
takes to complete scans for access points.

https://www.skyhook.com/blog/what-is-an-sdk-and-an-api

P2 Analyse an existing application that could be extended with a suitable API.

A simplified example would be when you sign into Facebook from your phone you are telling

the Facebook application that you would like to access your account. The mobile application

makes a call to an API to retrieve your Facebook account and credentials. Facebook would

then access this information from one of its servers and return the data to the mobile

application.
These type of APIs called web APIs are the most common but limited just to the web. There

are APIs for virtually every machine or system that expects to interact with other machines or

systems.

APIs have been around for a long time but only recently have gained in popularity. Companies

use this technology to gain an edge over others by finding more efficient ways to retrieve

information faster to serve the customer.

As I mentioned earlier web APIs are the not only ones that exist. We will dive into a few of

them in the next section.

Types of APIs

Web APIs are what gets utilized the most but there are others that exist that you should know

about. These are just as reliable and efficient as the web API but not well known.

REST (RESTful) API — stands for representational state transfer and delivers data using the

lightweight JSON format. Most public APIs use this because of its fast performance,

dependability and ability to scale by reusing modular components without affecting the system

as a whole.
This API gives access to data by using a uniform and predefined set of operations. REST APIs

are based on URLs and the HTTP protocol and are based on these 6 architectural constraints:

1. Client-server based — the client handles the front end process while the server handles the

backend and can be both replaced independently of each other.

2. Uniform interface — defines the interface between client and server and simplifies the

architecture to enable each part to develop separately

3. Stateless — each request from client to server must be independent and contain all of the

necessary information so that the server can understand and process it accordingly.

4. Cacheable — maintains cached responses between client and server avoiding any

additional processing
5. Layered system — layers are arranged hierarchically so that each one can only ‘see’ the

corresponding layer they are interacting with.

6. Code-on-demand — allows client functionality to be extended by downloading and

executing code in the form of applets and scripts. This simplifies clients by reducing the

number of features required to be pre-implemented.

Once you follow these defined constraints the API you create is said the be RESTful.

SOAP — Simple Object Access Protocol is a little more complex then REST because it

requires more upfront about how it sends its messages. This API has been around since the

late 1990s and uses XML to transfer data. It requires strict rules and advanced security that

requires more bandwidth.

This protocol does not have the ability to cache, has strict communication and needs every

piece of information about an interaction before any calls are even thought of to be processed.

XML-RPC — known as extensible markup language — Remote Procedure Calls. This

protocol uses a specific XML format to transfer data and is older and simpler than SOAP. A

client performs a RPC by sending an HTTP request to a server that implements XML-RPC

and receives the HTTP response.

JSON-RPC — is very similar to XML-RPC in that they work the same way except that this

protocol uses JSON instead of XML format. The client is typically software that calls on a

single method of a remote system.

https://towardsdatascience.com/what-is-an-api-and-how-does-it-work-1dccd7a8219e

P3 Build on an existing application framework to implement an API.

Custom API Customization

When creating Custom API and related request parameters and response properties,
it is important to understand that these API definitions are customizable by default.
This is what allows you to iterate and make changes to these items in your
unmanaged solution.

 Important

When you ship or deploy your solution, you should use a managed solution and we
recommend that you always set the Is Customizable managed property to these
components to false. This will prevent people using your managed solution from
modifying or deleting these components of your solution. Such changes could break
code written for the original definition of the Custom API. More
information Managed properties

Even when you have set the Is Customizable managed property to these

components to false, new request parameters and response properties can be
added to your Custom API. However, additional request parameters cannot be made
required. If you choose to allow custom processing steps on your custom api, these
additional parameters and properties added to the original definition can be used by
other plug-ins registered for the message created by your custom api. Because
custom request parameters can only be optional, the plug-in you provide for the
main operation of the custom api can ignore them and is not responsible for setting
any custom response properties.

Custom API tables/entities

The data that defines Custom APIs is in the following tables/entities:

 CustomAPI table/entity reference

 CustomAPIRequestParameter table/entity reference
  CustomAPIResponseProperty table/entity reference

See the following topics for detailed information about the columns/attributes you
can set for these tables/entities. You should review this as you plan the behavior for
your Custom API.

 CustomAPI Table Columns

 CustomAPIRequestParameter Table Columns
 CustomAPIRequestParameter Table Columns
Invoking Custom APIs
A Custom API creates a new message which can be invoked via the SDK or Web API.

Invoking Custom APIs from the Organization Service

You can choose to use either early-bound or late-bound code to invoke your custom
API. Use the CrmSvcUtil tool to generate helper request and response classes to
mirror the request and response properties of your custom API.

For late-bound code, or for a Custom API that you have marked as private, create
an OrganizationRequest with the unique name of your custom API and add
parameters with names matching the unique names of the request properties.

Entity-bound custom APIs have an implicit request property named Target that

should be set to an EntityReference of the record to invoke the API on.

You can access response properties from the parameters of the returned response.

C#Copy
var req = new OrganizationRequest("myapi_EscalateCase")
{
["Target"] = new EntityReference("incident", guid),
["Priority"] = new OptionSetValue(1)
};

var resp = svc.Execute(req);

var newOwner = (EntityReference) resp["AssignedTo"];

More information: Use messages with the Organization service.

Invoking Custom APIs from the Web API

You can invoke your API using PostMan. Use the steps described in Set up a Postman
environment to set up a PostMan environment that will generate the access token
you will need. Then, apply the steps described in Use Web API actions if your API is
an action. If it is a function, use the steps in Use Web API functions.

This is an example invoking a Custom API Action

named myapi_CustomUnboundAPI which has a single string request parameter
named InputParameter:

HTTPCopy
POST [Organization URI]/api/data/v9.1/myapi_CustomUnboundAPI
OData-MaxVersion: 4.0
OData-Version: 4.0
Content-Type: application/json; charset=utf-8

{
"InputParameter": "Value"
}

This is an example invoking a Custom API Function bound to the account entity
named myapi_CustomBoundAPI:

HTTPCopy
GET [Organization URI]/api/v9.1/accounts(ed5d4e42-850c-45b7-8b38-
2677545107cc)/Microsoft.Dynamics.CRM.myapi_CustomBoundAPI()
OData-MaxVersion: 4.0
OData-Version: 4.0
Content-Type: application/json; charset=utf-8

This is an example invoking a Custom API Function bound to the account entity
collection named myapi_CustomEntityCollectionBoundAPI:

HTTPCopy
GET [Organization
URI]/api/v9.1/accounts/Microsoft.Dynamics.CRM.myapi_CustomEntityCollectionBoundAPI
()
OData-MaxVersion: 4.0
OData-Version: 4.0
Content-Type: application/json; charset=utf-8

More information:

 Use Web API actions

 Use Web API functions
Write a Plug-in for your Custom API
Writing a plug-in to implement the main operation for your Custom API isn't
different from writing any other kind of plug-in, except that you do not use the Plug-
in Registration tool to set a specific step. You need to know the following
information:
  The name of the message
 The names and types of the parameters and properties.

The Request Parameter values will be included in the InputParameters.

You need to set the values for the Response Properties in the OutputParameters.

The following is a simple plug-in that reverses the characters in

the StringParameter and returns the result as the StringProperty.

C#Copy
using System;
using System.Linq;
using System.ServiceModel;
using Microsoft.Xrm.Sdk;

namespace CustomAPIExamples
{
public class Sample_CustomAPIExample : IPlugin
{
public void Execute(IServiceProvider serviceProvider)
{
// Obtain the tracing service
ITracingService tracingService =
(ITracingService)serviceProvider.GetService(typeof(ITracingService));

// Obtain the execution context from the service provider.

IPluginExecutionContext context = (IPluginExecutionContext)
serviceProvider.GetService(typeof(IPluginExecutionContext));

if (context.MessageName.Equals("sample_CustomAPIExample") &&
context.Stage.Equals(30)) {

try
{
string input =
(string)context.InputParameters["StringParameter"];

if (!string.IsNullOrEmpty(input)) {
//Simply reversing the characters of the string
context.OutputParameters["StringProperty"] = new
string(input.Reverse().ToArray());
}
}
catch (Exception ex)
{
tracingService.Trace("Sample_CustomAPIExample: {0}",
ex.ToString());
throw new InvalidPluginExecutionException("An error occurred
in Sample_CustomAPIExample.", ex);
}
}
else
{
 tracingService.Trace("Sample_CustomAPIExample plug-in is not
associated with the expected message or is not registered for the main
operation.");
}
}
}
}

P4 Design and complete a ‘white box’ test of the application, recording the results.

WhiteBox Testing Example

Consider the following piece of code

Printme (int a, int b) { ------------ Printme is a function

int result = a+ b;
If (result> 0)
Print ("Positive", result)
Else
Print ("Negative", result)
} ----------- End of the source code

The goal of WhiteBox testing in software engineering is to verify all the decision
branches, loops, statements in the code.

To exercise the statements in the above white box testing example, WhiteBox test
cases would be

 A = 1, B = 1
 A = -1, B = -3

White Box Testing Techniques

A major White box testing technique is Code Coverage analysis. Code Coverage
analysis eliminates gaps in a Test Case suite. It identifies areas of a program that
are not exercised by a set of test cases. Once gaps are identified, you create test
cases to verify untested parts of the code, thereby increasing the quality of the
software product

There are automated tools available to perform Code coverage analysis. Below are
a few coverage analysis techniques a box tester can use:
Statement Coverage:- This technique requires every possible statement in the
code to be tested at least once during the testing process of software engineering.

Branch Coverage - This technique checks every possible path (if-else and other
conditional loops) of a software application.

Apart from above, there are numerous coverage types such as Condition Coverage,
Multiple Condition Coverage, Path Coverage, Function Coverage etc. Each
technique has its own merits and attempts to test (cover) all parts of software
code. Using Statement and Branch coverage you generally attain 80-90% code
coverage which is sufficient.

Following are important WhiteBox Testing Techniques:

 Statement Coverage
 Decision Coverage
 Branch Coverage
 Condition Coverage
 Multiple Condition Coverage
 Finite State Machine Coverage
 Path Coverage
 Control flow testing
 Data flow testing

https://www.guru99.com/white-box-testing.html