APIs
Application Programming Interfaces serve as gateways for accessing and exchanging data and functionalities, making them integral to web applications, mobile apps, and cloud services.
API attacks occur when attackers exploit vulnerabilities in API design, implementation, or configuration to gain unauthorized access, exfiltrate sensitive information, manipulate data, or disrupt service availability.
Its main components are:
Interface: The set of rules and endpoints (methods and URLs) that describe how clients interact with the service
Endpoints: Specific paths or addresses where resources can be accessed, typically exposed over protocols like HTTP/S
Requests/Responses: The data formats (like JSON or XML) and protocols that define how information is sent to and received from the API
Authentication & Authorization: Security mechanisms (such as API keys, OAuth, JWT) used to verify identity and control access to resources or specific routes
They can be designed using various architectural styles that define how clients and servers interact, how data is exchanged, and how systems are structured. Here we find an overview of the most common styles:
REST
Representational State Transfer is an architectural style that defines standards for communication between computer systems on the web, characterized by:
Easy formatting: Most of the time, use JSON documents to transport data in an easy-to-use format
Being stateless: The server does not need to remember the client's state between requests. And the same applies to the client concerning the server, each message being independent, where any request or response can be understood on its own, without depending on the previous
Separating client and server responsibilities: The client-side code can change without affecting the server, and vice versa. As long as both sides agree on the message format, they can operate independently, modularly, and scalably.
These characteristics improve cross-platform flexibility, increase scalability by simplifying components, and facilitate the independent evolution of each side, where multiple clients can access the same REST endpoints, perform the same actions, and receive consistent responses.
Their structure is based on the CRUD concept (Create, Read, Update, Delete), which refers to the four basic operations you can perform on data. RESTful APIs are designed around CRUD operations, corresponding to HTTP methods:
POST: Add new records or entries (Create)
GET: Retrieve or view existing data (Read)
PUT/PATCH: Modify existing data (Update)
DELETE: Remove existing data (Delete)
SOAP
Simple Object Access Protocol defines a strict standard for how messages are formatted and transmitted between clients and servers, typically using XML typically over HTTP, or even network protocols like SMTP, or others.
It is characterized by:
Strict Standardization: Ensures consistent structure and behavior
Protocol Independence: Can operate over various protocols, not just HTTP
Extensibility: Supports features like security, transactions, and messaging reliability through standards such as WS-Security and WS-ReliableMessaging
SOAP APIs operate by wrapping requests and responses in XML envelopes. A client sends a SOAP message to an endpoint, which processes the request and returns a SOAP-formatted response
Its key components are:
Envelope: The top-level XML element that defines the start and end of the message
Header: Optional section of the envelope providing information such as authentication, transaction management, or routing
Body: Contains the actual message (requests and responses) encoded in XML
Fault: A standardized way to report errors within the response body
SOAP services usually provide a Web Services Description Language (WSDL) document, which is a machine-readable XML file that describes what operations the service exposes, where those operations are located, and what data types and formats are expected for requests and responses
REST vs SOAP
REST is popular for web and mobile applications due to its simplicity, performance, and flexibility. It’s best for lightweight, stateless, easily scalable APIs using simple data formats like JSON.
On the other side, SOAP is preferred in enterprise environments requiring formal contracts, stateful operations, built-in error handling, and advanced security and transactional support.
Here is a more detailed comparison of some of their features:
Architecture: REST is considered more of an architectural style. SOAP is oriented to a protocol specification
Data Format: REST typically JSON, and can support others. SOAP uses strictly XML
Message Size: REST is lightweight, less verbose. SOAP is heavier due to its XML structure
Transport Primarily: REST works over HTTP/S. SOAP can work over HTTP/S, SMTP, or others
Operations: REST maps CRUD to HTTP verbs. SOAP uses its own set of operations defined in WSDL
Statelessness: In REST, each request is independent. SOAP can be stateless or maintain state
Discoverability: REST uses documentation instead of a strict contract. SOAP uses contracts via WSDL
Error Handling: REST uses HTTP status codes. SOAP uses XML-based fault elements
Security: REST relies on HTTP/S, OAuth, or JWT. SOAP implements WS-Security
Standards: Rest don't have a strict standard, being flexible. SOAP uses a rigid standard, which includes WS extensions
Performance: REST is generally faster, using less bandwidth. SOAP is slower due to XML parsing
Use Cases: REST is used in public APIs, web/mobile apps, and lightweight services. SOAP is used in enterprise apps, payments, B2B, and complex workflows
Last updated