Scribd
Upload
45 views10 pages

fundamental principles of REST API design.pdf

The document outlines best practices for designing REST APIs, emphasizing resource-based endpoints, statelessness, and appropriate use of HTTP methods. It highlights how these principles enhance security, clarity, and scalability while providing examples of proper API endpoint structures. The focus is on making APIs predictable and easier to manage while aligning with Salesforce's data model and security protocols.

Uploaded by

abcxyz8485
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
45 views10 pages

fundamental principles of REST API design.pdf

The document outlines best practices for designing REST APIs, emphasizing resource-based endpoints, statelessness, and appropriate use of HTTP methods. It highlights how these principles enhance security, clarity, and scalability while providing examples of proper API endpoint structures. The focus is on making APIs predictable and easier to manage while aligning with Salesforce's data model and security protocols.

Uploaded by

abcxyz8485
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 10

@deedev

Mastering Salesforce Integration

Fundamental
principle of
REST API
design
@deedev
01

Resource-Based Endpoints:
Clarity Through Nouns
Design your API around resources,
which are the key entities or
objects that your API exposes.
Each resource should have a
unique URI (Uniform Resource
Identifier). The focus should be on
what the API provides access to,
not how to access it.
@deedev
02
Why it Enhances Security and
Clarity:
Predictability: Consistent use of nouns makes
the API easier to understand for developers,
reducing the likelihood of errors in
implementation and potential security
misconfigurations.
Logical Structure: A resource-based approach
naturally maps to your data model (e.g.,
Salesforce SObjects), making it easier to reason
about access controls and permissions. You can
often align your API endpoints with existing
object-level security in Salesforce.
Improved Governance: Clear resource
identification simplifies API management,
monitoring, and the application of security
policies at the resource level.
@deedev
03
Examples
Instead of: /getAccountDetails?
accountId=123 (action-oriented)
Use: /sobjects/Account/123 (resource-
oriented) to retrieve a specific Account
record.
Instead of: /createNewContact
Use: /sobjects/Contact with a POST
request to create a new Contact.
Instead of: /updateOpportunityStage?
opportunityId=456&stageName=Closed
Won
Use: /sobjects/Opportunity/456 with a
PATCH request and the stage in the request
body to update an Opportunity.
@deedev
04

Statelessness:
Independent Requests
Each request from the client to the
server must contain all the
information needed to understand
the request. The server should not
store any client state between
requests. If client state is needed, it
should be managed entirely by the
client (e.g., in cookies or request
parameters).
@deedev
05
Why it Enhances Security and
Clarity:
Reduced Server-Side Complexity: Statelessness
simplifies the server-side implementation, making it
easier to reason about security without worrying
about managing and securing sessions.
Improved Scalability: Stateless servers are easier
to scale horizontally as any server can handle any
request. This inherent scalability contributes to the
overall resilience and availability of your API.
Enhanced Security: By not maintaining session
state on the server, you reduce the risk of session-
based attacks like session hijacking or fixation.
Each request is treated independently and
authenticated/authorized based on the credentials
provided with that specific request (e.g., an OAuth
2.0 access token in the Authorization header).
@deedev
06

Appropriate Use of HTTP


Methods:
Leverage the standard HTTP
methods (GET, POST, PUT,
PATCH, DELETE) according to their
intended semantic meaning. This
ensures that clients and
intermediaries (like proxies and
caches) understand the purpose of
each request.
@deedev
07
Why it Enhances Security and
Clarity:
Predictable Behavior: Using standard methods
makes the API's behavior predictable. For example, a
GET request should always retrieve data and should
ideally be idempotent (making the same request
multiple times has the same effect as making it
once).
Security Enforcement by Infrastructure: Network
infrastructure like firewalls and proxies can be
configured to enforce rules based on HTTP methods
(e.g., allowing only GET and POST requests from
certain origins). Using methods correctly allows you
to leverage these built-in security mechanisms.
Improved Auditability and Logging: Standardized
method usage makes API logs more meaningful and
easier to audit for potential security breaches or
unexpected activity.
@deedev
06
Examples
GET: To retrieve a list of Accounts:
/sobjects/Account. To retrieve a specific
Account: /sobjects/Account/{accountId}.
POST: To create a new Lead:
/sobjects/Lead.
PUT: To replace an existing Case record
entirely: /sobjects/Case/{caseId} (less
common in Salesforce, PATCH is often
preferred).
PATCH: To partially update an existing
Contact record:
/sobjects/Contact/{contactId}.
DELETE: To delete a specific Custom
Object record:
/sobjects/MyCustomObject__c/{recordId}.
@deedev

Did you find


this useful ?
d b a ck !
r y an d s hare fee
ive it a t
G

You might also like