Web Services and REST Architecture

Service-oriented architecture enables travel websites to integrate multiple independent systems (airlines, hotels, car rentals) through web service calls, allowing a single interface to coordinate bookings across different organizations.

Programming

One Search, Many Systems

When you search for a vacation, one travel website may display flights, hotel rooms, and rental cars in one interface. However, these results do not necessarily come from one shared database. The airline, hotel company, and car rental company each maintain its own computers, data, and systems. The travel website acts as an orchestrator: it sends web service calls to those independent systems and combines their responses into one user experience.

How does the travel website coordinate separate airline, hotel, and car rental systems while presenting one booking interface?

Following the Search

Worked example

A Vacation Search

Trace what happens after a traveler enters search criteria for flights, hotels, and rental cars.

1
1. Enter criteria
The traveler enters search criteria into the travel website interface.
2
2. Send service calls
The travel website sends a query to the airline service, a query to the hotel service, and a query to the car rental service.
3
3. Query local databases
Each service queries the database owned by its organization: the airline database, hotel database, or car rental database.
4
4. Return results
The independent services return their results to the travel website.
5
5. Display one view
The travel website aggregates the results and displays them through its single interface.

Result

The traveler experiences one search, but the system has performed multiple independent queries against different organizations' systems.

What happens next as a search moves from the traveler through the travel website to independent partner services?

This is service-oriented architecture in practice. The travel website provides coordination, not ownership of every underlying dataset. Its interface makes the systems feel unified to the traveler, while the organizations remain independent behind that interface.

Authoritative Data Ownership

Definition

In this architecture, each organization maintains a single authoritative copy of its data in its own database. The travel website does not create a separate copy of the airline's flight inventory, the hotel's room inventory, or the car rental company's vehicle inventory. Instead, it queries the owning service through web service calls.

Which service owns each piece of reservation data, and how does the travel website access the authoritative copy?

Architecture	Data arrangement	Control
Service-oriented architecture	Each organization keeps its own authoritative data	Each data owner controls its service and rules
Monolithic architecture	One application owns a combined database for flights, hotels, cars, payments, and user accounts	The single application controls the combined data

The distinction is who owns and controls the data, not merely how many screens the traveler sees.

Boundaries and Permissions

Data ownership is reinforced through defined web service interfaces. A partner does not receive unrestricted access to another organization's entire database. The data owner decides which information can be queried, which actions can be performed, who may access the service, and under what conditions.

How are permissions enforced when the travel website requests or updates hotel-owned data?

In the real world

The source describes a hotel service that permits the travel website to query available rooms and make reservations, while not permitting access to guest payment information or past booking history. The hotel therefore remains autonomous even while participating in the travel website's booking experience.

From Booking to Payment

A complete booking is not one update to one shared database. It is a sequence of web service calls involving multiple systems. The travel website coordinates the interaction, while each participating system updates its own database independently.

What happens next as a user's booking request moves through partner services to reservation confirmation and payment processing?

Worked example

Tracing a Complete Booking

Explain the systems involved when a traveler books a flight, hotel, and car through one travel website.

1
Booking begins
The traveler submits a booking request through the travel website.
2
Reservations are requested
The website sends reservation requests to the airline, hotel, and car rental services.
3
Local systems update
Each organization updates its own database independently rather than relying on a shared travel-site database.
4
Payment is processed
The booking flow includes payment processing through a third system.
5
The result is presented
The travel website coordinates the responses and presents the reservation outcome through its unified interface.

Result

The traveler sees one coordinated transaction, but the underlying work crosses several independent services and databases.

Common Misunderstandings

Common mistake
Assuming the travel website owns all flight, hotel, and vehicle data.
What it looks like
Treating the unified search screen as evidence of one shared database.
Why it fails
The airline, hotel, and car rental organizations maintain their own systems and databases.
Do this instead
Think of the travel website as an orchestrator that queries independent services.
Common mistake
Assuming the travel website permanently copies partner inventory.
What it looks like
Using a travel-site copy as the final authority on whether a hotel room exists.
Why it fails
A copied inventory can become stale and can contribute to overbooking.
Do this instead
The travel website queries the owning service's authoritative data in real time.
Common mistake
Assuming a service partner can inspect an organization's entire database.
What it looks like
Believing that a hotel service must expose guest payment information and past booking history to the travel website.
Why it fails
Data owners control access through defined interfaces and can restrict both data and actions.
Do this instead
Separate permitted capabilities, such as room queries and reservations, from restricted information.
Common mistake
Treating a complete booking as one database transaction owned by the travel website.
What it looks like
Assuming one update changes airline, hotel, car rental, and payment records together inside one travel-site database.
Why it fails
A booking involves multiple sequential web service calls, and each system updates its own database independently.
Do this instead
Trace the booking as coordinated requests across independent services.

Check Your Model

MEDIUM

A hotel changes its available-room data after the travel website has already displayed search results. Explain which system should be treated as authoritative, why the travel website should query the hotel service rather than rely on its own copy, and how the hotel's service interface can restrict what the travel website is allowed to do.

Hints

Identify the organization that owns the room data.
Connect real-time querying with consistency and prevention of overbooking.
Distinguish allowed room queries and reservations from restricted hotel information.

Your attempt (not saved)

MEDIUM

Reconstruct the booking sequence in order: payment processing, search queries, reservation requests, and the travel website presenting the coordinated result. Then explain why each participating system updates its own database.