SOLID is an acronym for the first five object-oriented design (OOD) principles by Robert C. Martin (also known as Uncle Bob).

These principles establish practices that lend to developing software with considerations for maintaining and extending as the project grows. Adopting these practices can also contribute to avoiding code smells, refactoring code, and Agile or Adaptive software development.

SOLID stands for:

• S - Single-responsibility Principle

In programming, the Single Responsibility Principle (SRP) states that every module or class should have responsibility over a single part of the functionality provided by the software.

• O - Open-closed Principle

In programming, the Open/closed Principle (OCP) states that software entities (classes, modules, functions, etc.) should be open for extensions, but closed for modification.

• L - Liskov Substitution Principle

The Liskov Substitution Principle (LSP) is a fundamental principle in object-oriented programming that states that objects of a superclass should be able to be replaced with objects of a subclass without affecting the correctness of the program.

• I - Interface Segregation Principle

In programming, the Interface Segregation Principle (ISP) states that no client should be forced to depend on methods it does not use. Put more simply: Do not add additional functionality to an existing interface by adding new methods. Instead, create a new interface and let your class implement multiple interfaces if needed.

• D - Dependency Inversion Principle

In programming, the Dependency Inversion Principle (DIP) is a way to decouple software modules. This principle states that

• - High-level modules should not depend on low-level modules. Both should depend on abstractions.
• - Abstractions should not depend on details. Details should depend on abstractions.

APIs (application programming interfaces) come in many forms. API designers can choose from a range of protocols and standards when creating a new API, depending on the type of API they are creating, and its purpose. There are meny alternatives available:

REST

Most APIs use representational state transfer (REST), which incorporates the following guidelines:

• Client-server separation:

The client makes a request, and the server responds. This is the only way the two can interact.

• Stateless:

Each interaction is new and independent, and the server doesn’t remember previous requests.

• Uniform interface:

A common protocol governs requests and responses.

• Layered:

Requests and responses must maintain their formatting when passing through additional layers between the client and the API.

• Cacheable:

A response to a request should dictate if the resource can be cached and for how long.

The resulting APIs may be called “REST APIs” or “RESTful APIs.” They’re usually lightweight, scalable, and user friendly.

SOAP

Simple Object Access Protocol (SOAP) is a data transmission protocol that some APIs use. A SOAP API relies on an XML format and typically receives requests through HTTP. This protocol clearly defines how messages are sent and what information is included, making SOAP APIs more secure but also more difficult to implement.

RPC

Remote Procedure Call (RPC) is a protocol that executes scripts on a server via calls that use either JSON or XML. Since the API security and capabilities are limited, RPC APIs are less common than RESTful APIs and SOAP APIs. That said, they may be appropriate for some internal systems.

Web APIs

Web APIs are APIs that can be accessed using the HTTP protocol. The API defines endpoints, and valid request and response formats. Web APIs include the APIs used to communicate with the browser (see list). They may be services such as web notifications and web storage. Different web APIs feature varying levels of security and privacy, including open, internal and partner APIs. Multiple web APIs can be combined into a composite API - a collection of data or service APIs.

• Open APIs

Open APIs, also known as external or public APIs, are available to developers and other users with minimal restrictions. They may require registration, and use of an API key, or may be completely open. They are intended for external users (developers at other companies, for example) to access data or services. As an example, take a look at the provided by the UK government. Any developer can access it, without even registering, allowing app builders to include governmental data on restaurant standards in their apps.

• Internal APIs

In contrast to open APIs, internal APIs are designed to be hidden from external users. They are used within a company to share resources. They allow different teams or sections of a business to consume each other’s tools, data and programs. Using internal APIs has several advantages over conventional integration techniques, including security and access control, an audit trail of system access, and a standard interface for connecting multiple services.

• Partner APIs

Partner APIs are technically similar to open APIs, but they feature restricted access, often controlled through a third-party API gateway. They are usually intended for a specific purpose, such as providing access to a paid-for service. This is a very common pattern in software as a service ecosystem.

• Composite APIs

Composite APIs allow developers to access several endpoints in one call. These could be different endpoints of a single API, or they could be multiple services or data sources. Composite APIs are especially useful in microservice architectures, where a user may need information from several services to perform a single task. Using composite APIs can reduce server load and improve application performance, as one call can return all the data a user needs.