The Client and Server

Nội dung này hiện chưa có sẵn bằng ngôn ngữ của bạn.

Chapter 2 of Integration Architect, Part 1: Understanding Integration (See). Previous: Think Like an Integration Architect · Next: APIs, Contracts and Data Across the Wire.

In chapter 1, we zoomed out to the whole landscape, then picked one arrow and landed on it. This chapter is that one arrow, close up. However big the enterprise gets, every arrow on it comes down to the same thing: two processes talking, one call at a time. Somebody dials, and somebody answers.

Once you can see that call clearly, every mechanism in the rest of the course is a variation on it.

The ideas in this chapter

Somebody dials. There’s almost always a client who dials the phone to talk to a server. Who dials isn’t which way the data goes: you can call and push data, or call and ask for it.
One call can have many turns, and the client drives every one of them. If the line drops, the caller calls back. Servers don’t call out; a server that calls out has become a client.
Finding the server takes an address and a port. Localhost inside one machine, an IP address inside your own network, and a name outside it, so the machines behind the name can change. Your port is like the phone number, and someone has to be listening.
The client has to prove who it is. An open server can be flooded, and the data we move is almost always protected. Proving who you are often happens at a second address, which gives back a token: the wristband at a food festival.
The client–server tango. Two partners, two different parts, one dance. The client owns the whole round trip, because only the client sees it. The server owns what happens inside, and it fulfills the contract for success and for failure.
Client and server are parts in a call, not kinds of system. Two systems that call each other are both clients and both servers, so write it down per arrow.
You are the client. An API client makes the call for you, with no code. Read the status and the time, then break it on purpose and see who owns each failure.

The path through this chapter

Five modules, each standing on its own.

Who Dials the Phone. Somebody dials; push or ask; one call, many turns; and if the line drops, the caller calls back.
Finding the Server. Three distances, three kinds of address; your port is like the phone number; and someone has to be listening.
Knocking on the Door. An open door, proving who you are, the second address and its token, and the server’s side of the door.
The Client–Server Tango. Each side’s moves; the client owns the round trip; the server owns what happens inside; and two systems that are both.
You Are the Client. Your first call, how to read what comes back, three calls broken on purpose, and the start of your lab bench.

Each idea here is a seed. The request itself, its address, headers and body, and the contract behind it, is chapter 3. Signing in properly is chapter 12. How fast the arrows add up when every system calls every other is chapter 5, and what happens when calls fail for longer than a moment is chapter 13.

When you’ve finished, check yourself with the chapter study guide: a checklist for the exam, the habits beyond it, the words to know, and a few questions.

What an architect decides here

For every arrow, who dials, written down per call, not per system.
Where each server lives and how clients find it: an address that can change underneath, a port, and something listening.
How each client proves who it is, and as whom, and what it may do once it’s in.
Where each side’s job stops: the client’s errors, timeouts and retries; the server’s validation, logging and the errors its contract promises.
Which API client the team uses, and that test calls never carry real data.

Beyond the exam: when an AI agent calls a tool, the agent is the client. It dials, it proves who it is, and it owns the round trip like any client: if the call fails, it has to know that it failed. Chapter 21 comes back to agents as clients. The last two modules each end with what AI changes.

Explore

IETF, HTTP Semantics (RFC 9110) (opens in a new tab): the methods, headers and status codes behind every call in this chapter.
The Data Architect course, Proof of Delivery: the client owns the conversation, seen by a data architect.

Next: APIs, Contracts and Data Across the Wire