← Domain 2: Applications and Integration

2.4 · 7.4% of the exam · Topic 4 of 6

Software Engineering Foundations

A Claude application is still a service. The Messages call is HTTP and JSON, the client is asynchronous, and prompts, schemas, and model ids belong in version control and in review. Refactor the code into a unit a reviewer can check.

Learning objectives

Treat the Claude API as an HTTP JSON interface with status codes, timeouts, and retries that match the error.
Keep the client asynchronous so a model call does not block unrelated work.
Put prompts, tool schemas, and model ids in version control next to the code that sends them.
Review those artifacts the way you review code, because they change behavior.
Refactor a large unit before asking for a change that cannot be reviewed.

Detailed theory

The API is a service

Software engineering foundations are 7.4% of the exam: REST, JSON, asynchronous programming, version control, code review, and refactoring. They are how the mechanics in 2.3 sit inside an application someone else can run.

A Messages request is JSON over HTTPS. You authenticate, you send a body, you read a status, and you parse a body. A 429 and a timeout are not a 400 caused by a bad JSON shape. Retry the transient failure. Fix the body when the body is wrong. Do not retry a 400 as if the network had blipped.

Asynchrony

The call takes long enough that the client should not freeze unrelated work behind it. The usual tools are async functions, a timeout, and a cancellation path. Streaming is still asynchronous: tokens arrive over time, and the caller has to decide what to do with each event.

Independent requests can run together. Requests that need each other's result cannot. That is the same data-dependency rule as any other service client. A batch job that nobody is waiting on is the lifecycle and API choice from 2.2 and 2.3. The foundation underneath it is that the client does not pretend the work is instant.

Version control and review

The prompt, the tool schema, and the model id change what users get, and they often have no compiler error. Put them in the repository beside the function that sends them. A reviewer should see the behavior change in the diff.

Review asks whether the change matches the requirement, whether the JSON the client parses is the JSON the model was asked to produce, and whether a retry can duplicate a side effect. A prompt pasted into a dashboard and never diffed is invisible to that review.

Refactoring

A function that builds the request, calls the model, parses the result, and writes a database row is hard to test and hard to review. Split those steps. Parsing can be checked with a fixture. The HTTP call can be tested against a fake server. The side effect stays behind the code that is allowed to perform it.

The same split helps when a model edits the repository. A smaller unit with a clear contract is a smaller review. Refactoring is not a rewrite for its own sake. It is a structure that the next change can land in.

Core concepts

REST and JSON

What: HTTP methods, status codes, and a JSON body the client parses.
Why: The API fails in the ordinary ways: auth, bad body, rate limit, timeout, server error.
When: Every Messages call and every tool that wraps another HTTP API.
When not: You treat every non-200 as the same retry.

Asynchronous client

What: The call yields, times out, and can be cancelled. Independent calls can overlap.
Why: Model latency is long compared with local work.
When: A request, a stream, or a set of independent documents.
When not: The next call needs this call's output. Those stay ordered.

Version control

What: Prompts, schemas, and model ids committed with the caller.
Why: They are behavior. A missing diff is a missing review.
When: Any change a teammate should be able to revert.
When not: A secret. Tokens stay out of the repository.

Review and refactor

What: A human check of the diff, and a split that makes the next diff small.
Why: Language behavior will not fail the type checker.
When: A prompt, a schema, or a function that does too many jobs.
When not: You restyle code that already has a clear contract and no behavior change.

Practical examples

A 400 retried five times

The client sends a body the API rejects as invalid JSON. The retry loop treats every failure as transient and sends it again. The body is still invalid. The status said the request will not succeed until the client changes it. A timeout or a 429 is the retry case. The 400 is a fix-the-code case.

The prompt that was never in git

Support quality changes over a weekend. The only edit was a system prompt in a hosting panel. The git history of the service is clean, so review cannot see the behavior change and cannot revert it. Move the prompt into the repository next to the call.

Claude-specific considerations

SDK methods are still the REST API. A thrown error should tell you the status. Do not catch all exceptions and retry them.
Stream events are JSON too. A client that assumes one JSON object for the whole reply will break on a stream.
Tool inputs are JSON the model proposes and your code validates. Invalid tool arguments are a bad request for that tool, not a reason to resend the identical model call unchanged.
Keep API keys out of commits, prompts, and CLAUDE.md. Configuration in 2.6 is where shared files name variables, not secret values.

Architecture decisions

SituationChooseBecause

The API returns 429 or times out.Retry with a limit and a backoff.The same body can succeed later.

The API returns 400 for a malformed body.Fix the client. Do not retry the same body.The request is rejected as written.

Several documents do not depend on each other.Concurrent async calls, or batch if 2.3 says nobody is waiting.Waiting in series adds latency with no data dependency.

A prompt change should be reversible.Commit it beside the caller.Review and revert need a diff.

One function calls the model, parses, and writes a row.Split the side effect from the parse.The parse can be tested without the write.

Tradeoffs

A script that hides the prompt and retries everything is fast to write. A client that separates HTTP, parsing, and side effects is slower to write and possible to review. The left column is the script. The right column is the service client.

AxisOne scriptReviewable client

ErrorsAny failure is retried.Status codes choose retry or fix.

LatencyThe process blocks on each call, in order.Independent calls overlap. Dependent calls wait.

HistoryThe prompt lives outside git.The prompt is in the diff.

TestsOnly a live call can fail.Parsing has a fixture. HTTP has a fake.

Quick reference

The Claude API is HTTP and JSON. Parse the body. Read the status.
Retry timeouts and rate limits. Do not retry a body the server rejected.
The client is asynchronous. Overlap work that does not share a result.
Prompts, schemas, and model ids are versioned with the caller. Secrets are not.
Review the behavior change. The type checker will not.
Split request, parse, and side effect so each can be checked.

Decision rules for the exam

If the question says…The answer is likely…

"400 on invalid JSON, retry"Fix the body. Do not retry it

"429 or timeout"Limited retry

"prompt edited in a dashboard"Put it in version control

"one function does the call, the parse, and the write"Split them

"run these documents strictly in series"Only if each one needs the previous result

Common exam traps

TrapCorrect answer

Catching every error and retrying.A malformed request stays malformed.

Assuming the model text is already a parsed object.Parse it, then check the shape.

Leaving the prompt out of the pull request.Reviewers cannot see the behavior change.

Open the Domain 2 sheet

Exam tips

This repository has no practice questions stored for this skill. Do not borrow the architect tool-design bank. That bank is a different exam.
If the stem is a status code, separate a bad request from a transient failure.
If the stem is a behavior change with an empty git diff, the missing artifact is the prompt, schema, or model id.

Common mistakes

Logging the API key next to the request body.
Log the model id and the status. Keep the secret in the environment.
Serializing independent calls to make the code easier to read.
Keep the order only where there is a data dependency.
Refactoring by rewriting the prompt and the control flow in one diff.
Move structure first, then change behavior, so review can see which is which.

Practice questions

Original questions for this topic. They are study items, not questions from the live exam.

Scenario questions

Build exercise

Split a Claude client into reviewable pieces

Intermediate · 40 minutes

What you will learn

Which HTTP failures are retries.
Where the prompt lives.
How to test parsing without a live call.
How to keep a side effect out of the parser.

Step 1
Start from one function that does everything
Sketch a function that builds JSON, calls the API, parses a JSON answer, and writes a row.
Why: The foundation skill is seeing that this is four jobs.
You should see: One function with four comments marking the jobs.
Step 2
Map status codes
List 400, 401, 429, and a timeout, and write retry or fix next to each.
Why: REST errors are not one bucket.
You should see: 429 and timeout retry. 400 and 401 do not.
Step 3
Commit the prompt and a fixture
Put the system prompt in the repo and add a JSON fixture the parser must accept and one it must reject.
Why: Review and tests need artifacts, not a live key.
You should see: A prompt file and two fixtures, with the parser covered by the fixtures.
Step 4
Leave the write behind a function you did not call in the test
The fixture test must not touch the database.
Why: Refactoring is what makes that possible.
You should see: The test imports the parser only.

Review checklist

Checks are saved in this browser.

I can separate a 400 from a 429.
I parse JSON instead of trusting a string that looks like JSON.
I overlap only independent calls.
I keep prompts and schemas in git and secrets out of it.
I can review a prompt diff as a behavior change.
I can split a call, a parse, and a side effect.

Key takeaways

Claude's API is HTTP and JSON. Status codes decide retry versus fix.
The client is asynchronous. Dependencies decide what may overlap.
Prompts and schemas are code. They belong in review.
Refactor until the parse can be tested without the side effect.

Sources

CCDV-F exam guide, Domain 2 skill weights — Public blueprint summary: REST, JSON, asynchronous programming, version control, code review, refactoring.

Domain 2 overview · Quick reference

View progress