ข้ามไปยังเนื้อหา
SteveTechArcSteveTechArc Courses

Study guide

เนื้อหานี้ยังไม่มีในภาษาของคุณ

Study guide for chapter 3 of the Integration Architect course. Read the six modules first; this page helps you check what stuck.

About this study guide. It’s built only from this course’s own content and the published Salesforce exam guide’s list of objectives. It is never based on real exam questions, and it doesn’t claim to know what’s on the exam. If you’ve taken the exam, please don’t send me questions from it: the certification agreement forbids sharing them, and memorizing answers is the wrong way to become an architect anyway.

This chapter carries one exam objective, defining the components of a solution, from the Design Integration Solutions section, the biggest on the exam at 28%. It’s what’s on the wire in every integration: the request, the contract, serialization, the formats, schemas and mapping. It also supports API design (BLD-1), error handling (BLD-4) and resilience to change (BLD-6). The exam guide aligns to Summer ‘23; the versions and dates here are current, and dated.

For the Exam

Section titled “For the Exam”

Tick them off as you go. Each one links to where it’s taught.

The REST request (DES-2)

  • I know why integration moved onto the web’s ports, and that REST uses the web’s verbs and answers with data, most often JSON. (What REST Is, and How It Won)
  • I know the verbs: GET reads, POST creates, PATCH changes a little piece, PUT replaces the whole thing, DELETE removes it, and that a GET may be cached. (The Verb)
  • I know the server decides which verbs each address accepts, not the client. (The Verb)
  • I can read an address: the name to the left of the first slash, the path to the right, then parameters; and I know addresses are percent-encoded and can grow too long, so a long query may go in the body of a POST. (The Address)
  • I know the headers carry who you are (Authorization: Bearer), what you send (Content-Type) and what you want back (Accept). (The Headers)
  • I know a GET has no body, and POST, PUT and PATCH carry one. (The Body)

Status codes (supports BLD-4)

  • I can read a status by its first digit: 200s good news, 300s go somewhere else, 400s the client has something to fix, 500s the server does. (The Answer Starts With a Status)
  • I know 401 (who are you?), 403 (it’s not for you), 404 (I don’t have that) and 429 (too many requests: slow down). (The Answer Starts With a Status)
  • I know a 200 means the server did what the contract said, not that the data is right. (A 200 Isn’t Data Quality)

The contract (DES-2, supports BLD-1)

  • I know the server defines the contract, the client follows it, and the contract covers the errors as carefully as the answers. (What a Contract Is)
  • I know REST is a style, not a contract. (What a Contract Is)
  • I know SOAP’s contract is the WSDL, and that Salesforce still offers the Enterprise WSDL from Setup. (Before REST: The WSDL)
  • I can read an OpenAPI (formerly Swagger) file with five questions: servers, paths, parameters and request body, responses, and component schemas. (The OpenAPI File, Made Easy)
  • I know External Services takes OpenAPI 2.0 and 3.0, so a contract for it isn’t written in 3.1 or 3.2. (What’s in the Box: The Schemas)

Versions (supports BLD-6)

  • I know a version is a promise that an address keeps behaving the way it does now, and that a GET to /services/data/ lists an org’s API versions. (A Version Is a Promise)
  • I know Salesforce retired API versions 21.0 to 30.0 in Summer ‘25, and that versions 31.0 to 40.0 are deprecated from Summer ‘27 and retired in Summer ‘28. (A Version Is a Promise)
  • I know the hard part of a retirement is finding the outside clients still calling the old version. (A Version Is a Promise)
  • I version my own custom APIs: publish /v2, keep /v1 working for a while, and announce when it retires. (Your Own Contracts Need Versions Too)

Serialization (DES-2)

  • I can explain serialization and deserialization: an object taken apart into a stream to cross the process boundary, and rebuilt on the other side. (Across the Process Boundary)
  • I know both sides must know the format, and that the stream can be rebuilt into a different structure, in any language. (Any Language, Any Shape)
  • I know each place has its own encoding: percent-encoding in the address, the contract’s format in the body, Base64 for binary inside text, and that each makes the data bigger. (Every Place Has Its Own Encoding)
  • I know what serialization can quietly change: a time with no zone, a number’s precision, an amount with no currency, characters read in the wrong encoding. (What the Transporter Can Drop)

Formats (DES-2)

Schemas and transformation (DES-2)

  • I know a schema is the shape written down: JSON Schema for JSON, XSD for XML, the Avro schema for Avro. (A Schema Is the Shape, Written Down)
  • I know a schema catches the wrong shape at the door, as a 400, but not the right shape with the wrong meaning. (Checking Against the Schema)
  • I know the four kinds of mapping rule: rename, convert, reshape and look up; and the difference between a data and a protocol transformation. (Two Shapes, One Delivery)
  • I can choose where the mapping lives: in Salesforce (Flow, External Services, Apex, custom metadata, DataWeave in Apex), in middleware, or on the other side, and who owns it. (Where the Mapping Lives)

AI and the contract (supports BLD-1)

  • I never paste a secret, a token or real customer data into AI. (Two Rules Before You Paste)
  • I can check an AI-drafted contract for what one sample can’t show: required fields, allowed values, errors, sign-in and meaning. (What a Person Has to Check)
  • I test a draft contract against the real API in a tool, and have both owners agree to it. (Check It in the Tool)

Beyond the Exam

Section titled “Beyond the Exam”

The exam is the floor, not the ceiling. These are the habits from this chapter that an architect needs, whether or not a question ever asks about them.

  • Always, always check the status code, and then check the data.
  • The way in should equal the way out. Know what goes out and what comes back; don’t assume.
  • Never put secrets or personal data in an address.
  • Build on a recent API version, and know when each integration’s version retires.
  • Send times with a zone, money with its currency, and say the encoding: UTF-8.
  • Dealing with the answer is the biggest lift, not making the call.
  • A mapping nobody owns is the wrong answer. Wherever it lives, write down who owns it.
  • AI drafts, a person checks. Ask it to list what it guessed, and let the tool be the judge.

Words to Know

Section titled “Words to Know”
TermIn one line
RESTAn architectural style for the web: web verbs on addresses, answering with data
Verb (HTTP method)What you want to do: GET, POST, PUT, PATCH, DELETE
HeaderInformation about the call: who you are, what you send, what you want back
BodyThe data itself; optional, and never on a GET
Status codeThe server’s three-digit answer; the first digit says whose problem it is
ContractWhat a server promises its clients: verbs, nouns, payloads and errors
WSDLSOAP’s contract file
OpenAPI (Swagger)The usual contract file for REST, in YAML or JSON
API versionA promise that an address keeps behaving as it does now
SerializationTurning an object into a stream to cross the process boundary; deserializing rebuilds it
Base64A way to carry binary bytes as text, about a third bigger
AvroA binary format, read with its schema; used by the Pub/Sub API
SchemaThe shape of the data, written down so a machine can check it
MappingThe rules that turn one system’s shape into another’s
DataWeave in ApexMuleSoft’s transformation language, run inside Salesforce

Check Yourself

Section titled “Check Yourself”

Short scenarios in the style of the course. Decide your answer before you open it.

1. A client wants to change only a delivery's status, leaving everything else alone. Which verb, and who decides whether it's allowed?

PATCH: a little piece. PUT would replace the whole thing. And the server decides which verbs each address accepts, in its contract; send one it doesn’t list and the call fails. Reread The Verb.

2. A load of 10,000 records returns 200 OK. Is the integration done?

Not yet. A 200 means the server did what the contract said. Did all 10,000 arrive, were any rejected inside the answer, did a retry send something twice? Whether the data is right is a separate question. Reread A 200 Isn’t Data Quality.

3. Salesforce warns that requests are still arriving on an API version about to retire. What's the hard part?

Finding who’s calling. They’re outside clients, so you go to the logs, find the callers and trace each one to a team that can move it to a recent version. Reread A Version Is a Promise.

4. Deliveries made at 23:30 keep showing up on the next day in the partner's system. Every call returned 200. What would you check?

The time zone. A time sent without one is a guess, and a zone can move a delivery into the next day. Send times in ISO 8601 with the zone, and write it in the contract. Reread What the Transporter Can Drop.

5. A team wants to send delivery photos inside a JSON payload. What do you tell them?

Inside JSON, a photo has to become text, usually Base64, which makes it about a third bigger: a 2 MB photo becomes about 2.7 MB. Send it as a file, as binary, and it stays 2 MB. Reread Why Binary Still Rules.

6. A payload passes its JSON Schema, but the weights are in pounds where the contract says kilograms. Why didn't the schema catch it?

A schema checks the shape, not the meaning: a weight in pounds is still a number above zero. Check the meaning with the contract (units, time zones, which id is which), and with people when it matters. Reread Checking Against the Schema.

7. A partner's payload keeps changing, release after release, and every change means an Apex deployment. What could you do?

Move the mapping out of code, into custom metadata, so a mapping can change in production without changing code. Or, with many systems, put the mapping in middleware. Either way, write down who owns it. Reread Where the Mapping Lives.

8. AI drafted an OpenAPI file from one sample payload, with every field required. What else would you check before using it?

Required fields (one sample can’t show what’s optional), the allowed values, the errors and their shapes, the sign-in (a bearer token), and the meaning of each field. Then test it against the real API in a tool, and have both owners agree. Reread What a Person Has to Check.

Explore

Section titled “Explore”