LOCKEDIN / FORWARD-DEPLOYED ENGINEERING 101
Understand it.
Then build it.
You can be an experienced engineer and still be new to agents. Start with what each thing is and how it helps a person do useful work. Explore 58 original introductions across software, agents, cloud, security and delivery. Start here without a model key; each topic connects to deeper instruction and practice.
A place to start.
Choose a short reading route, or look up a concept below.
- 101UnderstandPlain language, visual walkthrough, vocabulary
- 102Build with guidanceOriginal lessons, examples and knowledge checks
- 103Practise and explainRunnable labs, failure cases and handover
Connect the software
See how resource addresses, HTTP methods and status codes organize a web API.
See the 9-concept route
For people who want the software vocabulary behind AI tools, or a refresher before their first local build.
- 01Terminal & CLIBegin with a person issuing a command to a program; the terminal is not itself an agent.
- 02ConfigurationUnderstand how that program receives its settings and why different processes can behave differently.
- 03JSON & schemasRead the messages programs exchange. Separate a field's name, type and meaning before following an API request.
- 04APIsMove from a person using a command to one program requesting something from another.
- 05RESTYou are here
- 06SDKsFollow the library code that turns a convenient method call into an API request.
- 07TestsDecide what observable behavior to check before trusting a change made by a person or an agent.
- 08GitSeparate editable files, selected snapshots and recorded commits. Match the tested content to the change you hand over.
- 09Claude CodeBring commands, configuration and checks into a bounded coding-assistant task.
Bookmark this page to return to this concept. The number shows your place in the reading route; it is not an assessment result.
An architectural style
What is a RESTful API?
REST means Representational State Transfer. It is a style for designing networked systems around resources and a uniform interface. In common HTTP APIs, URLs identify resources and methods such as GET and POST describe operations. Returning JSON alone does not make an API RESTful.
You need predictable interfaces before letting agents call enterprise services.
UNDERSTAND THE SYSTEM
One resource, different operations
REST is an architectural style; HTTP carries the exchange. An ETag labels a representation version. If-Match asks the service to change it only if that version still matches. Follow fictional tickets through the local lab cases; this diagram explains the exchanges, rather than running a server in your browser.
Read the connections in plain English
- 01Calling application → HTTP request
Select the operation and the exact representation the caller intends to send.
- 02HTTP request → Service checks
The local client sends actual HTTP to the service.
- 03Service checks → Resource state
Only accepted operations alter the ticket. Rejected writes preserve the existing state.
- 04Resource state → HTTP response
The service reports the result of the read, mutation or refusal.
- 05HTTP response → Client decision
The client compares the response to its intended work and the documented contract.
- 06Client decision → Calling application
Before another edit, inspect the current representation and reconcile the intended change.
Check your understanding: Does fetching a fresh ETag automatically make an old edit correct?
No. The tag guards a version comparison. The caller must inspect the current content and reconcile the intended change. In the lab's second edit, refreshing only the tag lets an old body overwrite the other editor's title.
CONNECT IT TO WHAT YOU KNOW
Start with something familiar.
Imagine a shared catalog: a stable address identifies each ticket, while agreed operations tell clients how to read or create one.
REST is a design style; HTTP is a communication protocol; JSON is a data format; FastAPI is one framework you can use to implement an HTTP API.
Words worth knowing
- Resource
- The thing identified and manipulated through the interface.
- Representation
- The data returned about a resource.
- Stateless request
- A request carries the information needed to understand it; servers can still store resource state.
Useful foundations
Open a definition and diagram here. Your lesson stays in place.
A software contractWhat is an API?
QUICK REFERENCE / 101
What is an API?
An application programming interface (API) is an agreed way for one piece of software to use another. It specifies operations, inputs, outputs and errors. Some APIs are local functions; a web API exchanges requests and responses across a network.
An agent becomes useful through connections to business systems. Those connections need clear contracts and failure behavior.
ONE EXAMPLE / FICTIONAL CASE
Follow the connections.
Read ticket T-104 with GET /tickets/T-104. Creating a ticket uses a different operation and requires write permission.
UNDERSTAND THE SYSTEM
One resource, different operations
REST is an architectural style; HTTP carries the exchange. An ETag labels a representation version. If-Match asks the service to change it only if that version still matches. Follow fictional tickets through the local lab cases; this diagram explains the exchanges, rather than running a server in your browser.
See what moves and why.
Read the connections in plain English
- 01Calling application → HTTP request
Select the operation and the exact representation the caller intends to send.
- 02HTTP request → Service checks
The local client sends actual HTTP to the service.
- 03Service checks → Resource state
Only accepted operations alter the ticket. Rejected writes preserve the existing state.
- 04Resource state → HTTP response
The service reports the result of the read, mutation or refusal.
- 05HTTP response → Client decision
The client compares the response to its intended work and the documented contract.
- 06Client decision → Calling application
Before another edit, inspect the current representation and reconcile the intended change.
Check your understanding: Does fetching a fresh ETag automatically make an old edit correct?
No. The tag guards a version comparison. The caller must inspect the current content and reconcile the intended change. In the lab's second edit, refreshing only the tag lets an old body overwrite the other editor's title.
Work through it, step by step.
Identify the resource
Choose a stable resource identifier rather than a vague action string.
What you have now: /tickets/T-104
Use method semantics
GET reads a representation and should not trigger a business write. POST commonly submits a creation request.
What you have now: Read and write have different contracts
Handle the result
Interpret status codes and response fields. Repeating a timed-out write needs a defined duplicate-prevention contract.
What you have now: Explicit success and failure handling
FROM RECOGNITION TO REASONING
Predict and inspect a resource through seven local HTTP cases.
- 01
Compare GET, POST, PUT and DELETE using the free REST API 101 lab.
- 02
Explain the final state after a repeated request and an older edit.
- 03
Change the creation count and the version-refresh behavior separately, then repair the flawed client sequence.
Seven request traces, two controlled edits and a read/change tool contract.
Compare your reasoning when you are ready
Idempotency concerns the intended effect, not identical response codes. A current version tag does not establish that the caller reviewed the current content. Reconcile the content and keep authorization outside model-generated arguments.
Keep notes in your own working copy. Moving through these cards does not record completion.
TURN THE IDEA INTO USEFUL WORK
You can now go deeper.
REST is a design style; HTTP is a communication protocol; JSON is a data format; FastAPI is one framework you can use to implement an HTTP API.
Academy lessons use your existing training access. Free guides stay open.