An Application programming interface is a software interface that helps in connecting between the computer or between computer programs. It is an interface that provides the accessibility of information such that weather forecasting. In simple words, you can say it is a software interface that offers service to the other pieces of software.

Best examples of web services APIs are- Rest(Representational State Transfer),SOAP(simple object access protocol)

Different types of APIs :

These are common types of APIs as follows. --There are four different types of APIs commonly used in web services: public, partner, private and composite.

1)Open APIs (Public)–
It is also called public APIs which are available to any other users. Open APIs help external users to access data and services. It is an open-source application programming interface in which we access with HTTP protocols.

2)Internal APIs(private) –
It is also known as private APIs, only an internal system exposes this type of APIs. These are designed for the internal use of the company rather than the external users.

3)Composite APIs –
It is a type of APIs that combines different data and services. The main reason to use Composites APIs is to improve the performance and to speed the execution process and improve the performance of the listeners in the web interfaces.

4)Partner APIs –
It is a type of APIs in which a developer needs specific rights or licenses in order to access. Partner APIs are not available to the public.

Applications of APIs in the real World:

Weather snippets, Entertainment,E-commerce website, Gaming,Login etc.

\==========================================================

##SOAP API:

Simple Object Access Protocol(SOAP) is a network protocol for exchanging structured data between nodes. It uses XML format to transfer messages. It works on top of application layer protocols like HTML and SMTP for notations and transmission. SOAP allows processes to communicate throughout platforms, languages and operating systems, since protocols like HTTP are already installed on all platforms.
SOAP was designed by Bob Atkinson, Don Box, Dave Winer, and Mohsen Al-Ghosein at Microsoft in 1998. SOAP was maintained by the XML Protocol Working Group of the World Wide Web Consortium until 2009.

Message Format:

• SOAP message transmits some basic information as given below:--

• Information about message structure and instructions on processing it.

• Encoding instructions for application defined data types.

• Information about Remote Procedure Calls and their responses.

  ##The message in XML format contains three parts

1. Envelope:
   It specifies that the XML message is a SOAP message. A SOAP message can be defined as an XML document containing header and body encapsulated in the envelope. The fault is within the body of the message.

2. Header:
   This part is not mandatory. But when it is present it can provide crucial information about the applications.

3. Body:
   It contains the actual message that is being transmitted. Fault is contained within the body tags.

4. Fault:
   This section contains the status of the application and also contains errors in the application. This section is also optional. It should not appear more than once in a SOAP message.

   Sample Message:

   Content-Type: application/soap+xml

   <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">

   <env:Header>

   <m:GetLastTradePrice xmlns:m="Some-URI" />

   </env:Header>

   <env:Body>

   <symbol xmlns:p="Some-URI" >DIS</symbol>

   </env:Body>

   </env:Envelope>

   Advantages of SOAP

   1. SOAP is a light weight data interchange protocol because it is based on XML.

   2. SOAP was designed to be OS and Platform independent.

   3. It is built on top of HTTP which is installed in most systems.

   4. It is suggested by W3 consortium which is like a governing body for the Web.

   5. SOAP is mainly used for Web Services and Application Programming Interfaces

      ##REST API

      Representational State Transfer (REST) is an architectural style that defines a set of constraints to be used for creating web services. REST API is a way of accessing web services in a simple and flexible way without having any processing.

      REST technology is generally preferred to the more robust Simple Object Access Protocol (SOAP) technology because REST uses less bandwidth, simple and flexible making it more suitable for internet usage. It’s used to fetch or give some information from a web service. All communication done via REST API uses only HTTP request.

      Working: A request is sent from client to server in the form of a web URL as HTTP GET or POST or PUT or DELETE request. After that, a response comes back from the server in the form of a resource which can be anything like HTML, XML, Image, or JSON. But now JSON is the most popular format being used in Web Services.

      

      In HTTP there are five methods that are commonly used in a REST-based Architecture i.e., POST, GET, PUT, PATCH, and DELETE. These correspond to create, read, update, and delete (or CRUD) operations respectively. There are other methods which are less frequently used like OPTIONS and HEAD.

      • GET: The HTTP GET method is used to read (or retrieve) a representation of a resource. In the safe path, GET returns a representation in XML or JSON and an HTTP response code of 200 (OK). In an error case, it most often returns a 404 (NOT FOUND) or 400 (BAD REQUEST).

• POST: The POST verb is most often utilized to create new resources. In particular, it’s used to create subordinate resources. That is, subordinate to some other (e.g. parent) resource. On successful creation, return HTTP status 201, returning a Location header with a link to the newly-created resource with the 201 HTTP status.

NOTE: POST is neither safe nor idempotent. (An idempotent HTTP method is a HTTP method that can be called many times without different outcomes.)

• PUT: It is used for updating the capabilities. However, PUT can also be used to create a resource in the case where the resource ID is chosen by the client instead of by the server. In other words, if the PUT is to a URI that contains the value of a non-existent resource ID. On successful update, return 200 (or 204 if not returning any content in the body) from a PUT. If using PUT for create, return HTTP status 201 on successful creation. PUT is not safe operation but it’s idempotent.

• PATCH: It is used to modify capabilities. The PATCH request only needs to contain the changes to the resource, not the complete resource. This resembles PUT, but the body contains a set of instructions describing how a resource currently residing on the server should be modified to produce a new version. This means that the PATCH body should not just be a modified part of the resource, but in some kind of patch language like JSON Patch or XML Patch. PATCH is neither safe nor idempotent.

• DELETE: It is used to delete a resource identified by a URI. On successful deletion, return HTTP status 200 (OK) along with a response body.

Idempotence: An idempotent HTTP method is a HTTP method that can be called many times without different outcomes. It would not matter if the method is called only once, or ten times over. The result should be the same. Again, this only applies to the result, not the resource itself.

1. a = 4 // It is Idempotence, as final value(a = 4)

// would not change after executing it multiple

// times.

2. a++ // It is not Idempotence because the final value

// will depend upon the number of times the

// statement is executed.

Request and Response:-

Now we will see how request and response work for different HTTP methods. Let’s assume we have an API for all students data .

• GET: Request for all Students.

Request

GET:/api/students

• POST: Request for Posting/Creating/Inserting Data

Request

POST:/api/students

• PUT or PATCH: Request for Updating Data at id=1

Request

PUT or PATCH:/api/students/1

• DELETE: Request for Deleting Data of id=1

Request

DELETE:/api/students/1

RESTful web services are very popular because they are light weight, highly scalable and maintainable and are very commonly used to create APIs for web-based applications.

Remote Procedure Call (RPC)

Remote Procedure Call is a software communication protocol that one program can use to request a service from a program located in another computer on a network without having to understand the network's details. RPC is used to call other processes on the remote systems like a local system. A procedure call is also sometimes known as a function call or a subroutine call.

RPC uses the client-server model. The requesting program is a client, and the service-providing program is the server. Like a local procedure call, an RPC is a synchronous operation requiring the requesting program to be suspended until the results of the remote procedure are returned. However, the use of lightweight processes or threads that share the same address space enables multiple RPCs to be performed concurrently.

How does RPC work?

When a remote procedure call is invoked, the calling environment is suspended, the procedure parameters are transferred across the network to the environment where the procedure is to execute, and the procedure is then executed in that environment.

When the procedure finishes, the results are transferred back to the calling environment, where execution resumes as if returning from a regular procedure call.

During an RPC, the following steps take place:

1. The client calls the client stub. The call is a local procedure call with parameters pushed onto the stack in the normal way.

2. The client stub packs the procedure parameters into a message and makes a system call to send the message. The packing of the procedure parameters is called marshalling.

3. The client's local OS sends the message from the client machine to the remote server machine.

4. The server OS passes the incoming packets to the server stub.

5. The server stub unpacks the parameters -- called unmarshalling -- from the message.

6. When the server procedure is finished, it returns to the server stub, which marshals the return values into a message. The server stub then hands the message to the transport layer.

7. The transport layer sends the resulting message back to the client transport layer, which hands the message back to the client stub.

8. The client stub unmarshalls the return parameters, and execution returns to the caller.

Types of RPC

There are several RPC models and distributed computing implementations. A popular model and implementation is the Open Software Foundation's (OSF) Distributed Computing Environment (DCE). The Institute of Electrical and Electronics Engineers (IEEE) defines RPC in its ISO Remote Procedure Call Specification, ISO/IEC CD 11578 N6561, ISO/IEC, November 1991.

Examples of RPC configurations include the following:

• The normal method of operation where the client makes a call and doesn't continue until the server returns the reply.

• The client makes a call and continues with its own processing. The server doesn't reply.

• A facility for sending several client nonblocking calls in one batch.

• RPC clients have a broadcast facility, i.e., they can send messages to many servers and then receive all the resulting replies.

• The client makes a nonblocking client/server call; the server signals the call is completed by calling a procedure associated with the client.

RPC spans the transport layer and the application layer in the Open Systems Interconnection (OSI) model of network communication. RPC makes it easier to develop an application that includes multiple programs distributed in a network. Alternative methods for client-server communication include message queueing and IBM's Advanced Program-to-Program Communication (APPC).

Pros and cons of RPC

Though it boasts a wide range of benefits, there are certainly a share of pitfalls that those who use RPC should be aware of.

Here are some of the advantages RPC provides for developers and application managers:

• Helps clients communicate with servers via the traditional use of procedure calls in high-level languages.

• Can be used in a distributed environment, as well as the local environment.

• Supports process-oriented and thread-oriented models.

• Hides the internal message-passing mechanism from the user.

• Requires only minimal effort to rewrite and redevelop the code.

• Provides abstraction, i.e., the message-passing nature of network communication is hidden from the user.

• Omits many of the protocol layers to improve performance.

On the other hand, some of the disadvantages of RPC include the following:

• The client and server use different execution environments for their respective routines, and the use of resources (e.g., files) is also more complex. Consequently, RPC systems aren't always suited for transferring large amounts of data.

• RPC is highly vulnerable to failure because it involves a communication system, another machine and another process.

• There is no uniform standard for RPC; it can be implemented in a variety of ways.

• RPC is only interaction-based, and as such, it doesn't offer any flexibility when it comes to hardware architecture.