Building Apex REST and SOAP services and clients
What to consider when Salesforce provides a custom API (system context and how to enforce sharing and field security, API allocation, package namespaces, unsupported content types, heap-safe responses, WSDL from webservice methods) and when it consumes one (SOAP 1.1 only, no WS-Security in generated classes, idempotency keys, response size limits and paginated APIs).
Given a use case that includes technical requirements, constraints, or drivers, identify the considerations when designing and implementing an API(s), both Salesforce as an API provider and Salesforce as an API consumer.
~8 min read · 13 practice questions ·
What the exam expects
- Decide between the standard REST or SOAP API, a custom Apex REST service and an Apex SOAP web service when Salesforce is the provider.
- Secure a custom Apex service: know it runs in system context and how sharing, object and field security are enforced in code.
- Predict how custom services hit limits: API allocation, governor limits, content types, serialization.
- Decide how Apex consumes an external SOAP or REST API: WSDL2Apex versus HTTP classes, supported SOAP standards, WS-Security, idempotency, response size and pagination.
Key terms: Apex REST (an @RestResource class served under /services/apexrest/); Apex web service (a global class with webservice static methods and its own WSDL); system context (code runs without the caller's permissions); WSDL2Apex (Setup's Generate from WSDL, which builds stub classes for callouts); idempotency key (a unique ID the caller sends so the receiver can detect repeats).
Key facts
- Detail
- Always system context; sharing with
with sharingor user-mode operations; set object and field access explicitly (database operations default to user mode only at API 67.0+)
- Detail
- Counts against API limits; all Apex governor limits apply
- Detail
multipart/form-data
- Detail
/services/apexrest/<namespace>/<mapping>
- Detail
- WSDL 1.1, SOAP 1.1, WSI-Basic Profile 1.1; no WS-Security in generated proxies
- Detail
- Default 10 s; maximum 120,000 ms per callout; 120 s cumulative
- Detail
- 6 MB synchronous, 12 MB asynchronous; counts toward heap
- Detail
- 1 MB maximum
- Detail
- Need
Database.AllowsCallouts; one child job per running job
Sources for this section (9)
- Exposing Data with Apex RESTdeveloper.salesforce.com (opens in a new tab)
- Release notehelp.salesforce.com (opens in a new tab)
- Introduction to Apex RESTdeveloper.salesforce.com (opens in a new tab)
- Apex REST Methodsdeveloper.salesforce.com (opens in a new tab)
- Integration Patternsarchitect.salesforce.com (opens in a new tab)
- Callout Limits and Limitationsdeveloper.salesforce.com (opens in a new tab)
- Execution Governors and Limitsdeveloper.salesforce.com (opens in a new tab)
- Asynchronous Callout Limitsdeveloper.salesforce.com (opens in a new tab)
- Queueable Apexdeveloper.salesforce.com (opens in a new tab)
- Why must a custom Apex REST service enforce field-level security in code?
- When is a custom Apex web service justified over the standard SOAP API?
- Which SOAP standards can Apex callouts consume?
- When should a large or paginated callout move into a Queueable job?
The questions are free to read. Answers with their sources and self-grading are included with the pack.
Keep reading with the Integration Architect pack
- Core concepts
- Exam traps
- Worked scenario
The pack includes:
- All 25 lessons of the Integration Architect guide, with reading progress
- Interactive decision walks and step-by-step sequence steppers
- Inline practice questions and one-click topic practice (13 questions for this lesson)
- An official source cited for every claim
- An AI tutor that answers from the guide
- Unlimited timed practice exams