Application Programming Interface (API) serves as an interface that enables applications or computer programs to communicate with each other directly. It is used to expose functionalities and procedures to the outside world through a service path or URL.
API plays a big part in our network by configuring and monitoring computer systems, network devices, or applications that involve programmatically interacting through software.
APIs are built for real-time programmatic access (built for computers to interact with each other without human intervention) and can be used for connecting to an individual or multiple devices on our network simultaneously.
Web services are the type of API that typically runs over HTTP/HTTPS. However, some web services, such as the Simple Object Access Protocol (SOAP), can use different transports such as Simple Mail Transfer Protocol (SMTP). Web services don’t necessarily use HTTP, but this is almost always the case and is usually assumed unless mentioned otherwise.
The two main types of APIs used for web service that runs over the Internet and typically use HTTP/HTTPS are SOAP and REST.
Simple Object Access Protocol (SOAP) API
SOAP APIs are standard communication protocol systems that permit different operating systems like Linux and Windows to communicate. It was developed by Microsoft and is commonly used with HTTP transport with XML data format to access web services. It has three well-known characteristics.
A more reliable way to communicate between applications is over HTTP, as it is supported by all Internet browsers and servers for web service. SOAP was created to accomplish this.
SOAP web services provide a way to communicate between applications running on different operating systems, with different technologies and programming languages.
SOAP messages are nothing but XML documents and can contain four elements.
Representational State Transfer (REST) API
Restful web services use HTTP methods to collect and manipulate data. A URL identifies every resource, and every resource should support the HTTP common operations. It offers a consistent way to interact with APIs from multiple vendors. Below are the most common HTTP “CRUD” functions and their associated use cases:
REST Response Codes
Another interesting standard that REST services can benefit from when based on HTTP is the usage of HTTP status codes. The status code is a number that summarizes the response associated with it. These are the status codes responses from servers that should help the client solve the problem:
These codes are grouped into five sets, based on their meaning:
- 1xx: Informational and defined only under HTTP 1.1. (e.g., 101 means Switching Protocols)
- 2xx: The request is successful. Here’s your content. (e.g., 200 means OK)
- 3xx: The resource was redirected somehow to somewhere. (e.g., 301 means Moved Permanently)
- 4xx: The client or source of the request did something wrong. (e.g., 401 Unauthorized, 403 Forbidden, 404 Not Found, etc.)
- 5xx: Server crashed due to some error in its code. (e.g., 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, etc.)
API constraints refer to the architectural constraints or design guidelines that should be followed when using the APIs. We will use REST or RESTful APIs to discuss constraints.
- Client-server architecture: A server is in charge of handling the set of services, and it listens for requests regarding the said services. In turn, the requests are made via a connector by a client system needing one of those services.
- Stateless: each request done from the client must have all the information required for the server to understand it. The server does not store information based on the client request.
- Cacheability: every response to a request must be explicitly or implicitly set as cacheable.
- Uniform Interface: By keeping a uniform interface between components, it provides simplicity on the client’s job when it comes to interacting with the system.
- Layered System: This system’s constraints enable network-based intermediaries, like gateways and proxies, to be transparently deployed between the server and the client using the web’s uniform interface.
- Code-on-Demand: servers can temporarily extend or customize the functionality of a client by transferring executable code. The code provided by the server can be downloaded and executed by the client.
SOAP vs REST
Use SOAP API if you are dealing with transactional operations and you already have an audience that is satisfied with this technology. Use REST web services if you’re focused on wide-scale API adoption or if your API is targeted at mobile apps.
- Follows a formal enterprise approach
- It is platform- and language-independent.
- Information about objects is communicated to clients.
- SOAP bypasses all firewalls.
- Uses high bandwidth to communicate metadata
- Hard to implement
- Unpopular among web and mobile developers
SOAP Use Cases:
- Financial services
- Payment gateways
- Telecommunication services
- Follows the philosophy of the Open Web
- Relatively easy to implement and maintain
- Separates client and server implementations
- A single entity doesn’t control communication
- The client can store information to prevent multiple calls
- Able to return data in multiple formats (JSON, XML, etc.)
- Works on top of the HTTP protocol only
- Must enforce security and authorization on top of it
REST Use Cases:
- Social media services
- Social networks
- Webchat services
- Mobile services
Download our Free CCNA Study Guide PDF for complete notes on all the CCNA 200-301 exam topics in one book.
We recommend the Cisco CCNA Gold Bootcamp as your main CCNA training course. It’s the highest rated Cisco course online with an average rating of 4.8 from over 30,000 public reviews and is the gold standard in CCNA training: