Authentication and API Security

A Feature Built from Services

Imagine a travel booking application that must search flights, check hotel availability, process payments, and manage user accounts. One design is to place all of this functionality inside one application. Another design is to use specialized services: a flight-data service, a hotel-inventory service, a payment service, and a user-account service. The application can call these services and combine their responses into one user experience.

The API Contract

The word contract is important. A service's API tells another application how to make a request and what format the response will have. The calling application does not need to know how the service performs its work internally. It needs to follow the published rules.

Following One Request

To understand service integration, trace one request from the application to a service and back. The application first determines what service functionality it needs. It then creates a request that follows the service's published API rules. The request can include what is being asked for, parameters that customize the request, and authentication credentials if the service requires them.

1. The application identifies the service it needs.
2. The application sends a request that follows the service's API contract.
3. The request includes the requested operation, any parameters, and authentication credentials if required.
4. The service validates the request against its API contract.
5. The service processes the request and sends a response.
6. The response contains requested data in a standardized format such as JSON or XML, along with a status code indicating success or failure.
7. The application parses the response and uses it to continue its work.

Rules That Enable Integration

Integration works because both sides can rely on the same published rules. The application knows what request information to provide. The service knows how to validate that request and what response structure to return. The application can then parse the standardized response without needing to understand the service's internal implementation.

This arrangement also separates responsibilities. A hotel service team can improve its search algorithm without touching flight-search code. A payment service can upgrade its security without affecting hotel-availability checks, provided the service interaction continues to follow the published contract.

Authentication in the Request

Authentication belongs to the request-and-response interaction when a service requires it. The source specifies that a request can include authentication credentials. The service then validates the request against its API contract, processes the request, and returns a response with requested data and a status code indicating success or failure.

Mistakes in Service Integration

• Treating an API as the service's internal implementation.

  An API is the published contract for requesting and receiving services. The service can keep its internal implementation separate.

  Fix: Use the documented request and response rules without depending on the service's internal details.

• Calling a service without following its contract.

  The service validates requests against its API contract, and the calling application relies on the published response format.

  Fix: Read and follow the service's published rules for requests, parameters, credentials if required, response data, and status information.

• Assuming that several services automatically form one application.

  In the source example, the application acts as the orchestrator and coordinates the services.

  Fix: Design the application to orchestrate service calls and combine their responses into a cohesive user experience.

• Ignoring the cost of network dependence.

  SOA also introduces network dependencies and distributed system complexity.

  Fix: Recognize both the modular benefits and the additional complexity of coordinating independent services across a network.

Practice the Trace

Essential Takeaways

1. An API is a published contract between applications that defines the rules for requesting and receiving services.
2. A monolithic application is a single self-contained application, while SOA composes an application from multiple independent services connected across a network.
3. Each service can expose its own contract, allowing a calling application to use the service without understanding its internal implementation.
4. The calling application orchestrates service requests, receives standardized responses and status information, and combines the results into a larger feature.
5. Authentication credentials may be included in an API request when the service requires them; the exact security mechanism must come from the service's published rules.