The document provides an overview of the Salesforce REST API, explaining its architecture, principles, and functionalities, including how to interact with Salesforce resources through HTTP methods. It details the REST architectural style, emphasizing the importance of statelessness, caching, uniform interfaces, and the use of friendly URLs to optimize API calls. Additionally, it discusses the differences between REST, SOAP, and Bulk APIs, and outlines how to access available API versions and perform CRUD operations.

1. @patlatus www.patlatus.wordpress.com
S A L E S F O R C E D E V E L O P M E N T T E A M L E A D
S A L E S F O R C E C E R T I F I E D F O R C E . C O M A D V A N C E D D E V E L O P E R
Bohdan Dovhan
Salesforce REST API:
Remote SOQL, SOSL, CRUD and other available actions
Headshot optional

2. REST Design
Salesforce REST API
REST API Demo Application
Knowledge of REST will help to understand
how web works and knowledge of REST API
will help to implement custom integration to
Salesforce
Overview

3. Representationalstatetransfer
Representational state transfer is the software architectural style of the World Wide Web. The purpose of REST
architecture is to induce
* Performance
* Scalability
* Simplicity
* Modifiability
* Visibility
* Portability
* Reliability

4. Roy Fieldingcoined the term
The term representational state transfer was introduced and defined in 2000 by Roy
Fielding in his doctoral dissertation at UC Irvine. REST has been applied to describe
desired web architecture, to identify existing problems, to compare alternative
solutions and to ensure that protocol extensions would not violate the core
constraints that make the web successful. Fielding used REST to design HTTP 1.1
and Uniform Resource Identifiers (URI).

5. RESTfulsystems
To the extent that systems conform to the constraints of REST they can be called RESTful. RESTful systems typically,
but notalways, communicate over Hypertext Transfer Protocol (HTTP) with the same HTTP verbs (GET, POST,PUT,
DELETE, PATCH ) that web browsers use to retrieveweb pages and to send data toremote servers. REST systems
interface with external systems as web resources identified by Uniform Resource Identifiers (URIs), for example
/people/tom, which can be operated upon using standard verbs such as GET /people/tom.

6. Examples
* Google Glass API
* Twitter API
* AmazonWeb Services
* Atom (RESTful alternative to RSS)
* Tesla ModelS uses RESTful calls to communicate between mobile devices and car:http://docs.timdorr.apiary.io/

7. UnderstandingForce.com REST Resources
A REST resource is an abstraction of a piece of information, such as a single data record, a collection of records, oreven dynamic
real-time information. Each resource in the Force.comREST API is identified by a named URI, and is accessed using standard HTTP
methods (HEAD, GET, POST, PATCH, DELETE). TheForce.comREST API is based on the usage ofresources, their URIs, and the links
between them.
NOTA BENE: no “PUT” verb.PUT was used to replace theentire resource, not used in Force.comREST API

8. UnderstandingForce.com REST Resources
You use a resource tointeract with your Salesforce or Force.comorganization. Forexample, you can:
Retrievesummary information aboutthe API versions available to you.
Obtain detailed information about a Salesforce objectsuch as an Account or a custom object.
Obtain detailed information about Force.comobjects, such as User or a custom object.
Perform a query orsearch.
Update or delete records.

9. Whatis the difference between HEAD andGET?
TheHTTP methods are used to indicate the desired action, such as retrieving information, as well as creating, updating, and
deleting records.
• HEAD is used to retrieve resource metadata. Thesame as GET but lacks resp. body
• GET is used to retrieve information, such as basic resource summaryinformation.
• POST is used to createa new object.
• PATCH is usedto update a record.
• DELETE is used to delete a record.

10. REST Principles: StatelessandCaching
Stateless
Each request from client to servermustcontain all the information necessaryto understand the request, and not use any stored
context onthe server.However, the representations ofthe resources areinterconnected using URLs, which allow the client to
progress between states.
Caching behavior
Responses are labeled as cacheable or non-cacheable.

11. REST Principles: UniformityandNaming
Uniform interface
All resources areaccessedwith a generic interface over HTTP.
Named resources
All resourcesarenamedusing a base URI that follows your Force.comURI.

12. REST Principles: Layers and Authentication
Layered components
TheForce.comREST API architecture allows for the existence of such intermediaries as proxy servers and gateways toexist
between the client and the resources.
Authentication
TheForce.comREST API supports OAuth 2.0 (an open protocol to allow secure API authorization).

13. JSON vs. XML
Support for JSON and XML
JSON is the default. You can usethe HTTP ACCEPT headertoselect either JSONor XML, orappend .json or.xml to the URI (for
example,/Account/001D000000INjVe.json).
TheJavaScript Object Notation (JSON)format is supported with UTF-8. Date-time information is in ISO8601 format.
XML serialization is similar to SOAPAPI. XML requests are supported in UTF-8 and UTF-16, and XML responses areprovided in
UTF-8.

14. RelationshipURLs a.k.a. “Friendly”
Why maketwo API calls when you canmake just one? A friendly URL provides an intuitive way to construct REST API requests and
minimizes the numberof round-trips between your app and Salesforce org. Friendly URLs are available in API version 36.0 and
later. This functionality is exposed via the SObject Relationships resource.
Accessing a contact’s parentaccount without a friendly URL involves requesting the contact recordusing the SObject Rows
resource. Thenyou examinethe account relationship field to obtain the account ID and request the account recordwith another
call to SObjectRows. Using a friendly URL, you can access the account ina single call directly from the contact’s path:
/services/data/v36.0/sobjects/contact/id/account.

15. REST API vs. SOAP API vs. Bulk API
SOAPAPI may bemore convenient to process multiple records ( it has the same method for oneormultiple records DML operation
while REST API has different resource for multiple records DML operation/composite/tree/ )
If you need to process hugeamount of data, use Bulk API
While it is possible toqueryorsearchfor multiple records in REST API using onerequest, toperform UpdateDelete operations
you need to perform one request pereach recordoruse /composite/batch/ to unite DML operations in a batch

16. How can we know availableversions?
Versions resource. URI: /
Formats: JSON, XML; HTTP Method: GET;Authentication: none; Parameters: none
Lists summary information about each Salesforce version currently available, including the version, label, and a link to each
version's root.
http://login.salesforce.com/services/data/
http://login.salesforce.com/services/data/v37.0 Is Summer’16 is on your production?

18. List AvailableREST Resources

20. Get a List of Objects

22. Get Fieldand Other Metadatafor an Object

23. Get Field and Other Metadatafor an Object

24. Running SOQLquery
select Id, Name from Organization

25. select Id, Name from ApexClass

26. Running SOSLsearch
FIND {REST API DEMO} RETURNING ApexClass (Id,Name),ApexPage (Id,Name)

27. find {oil} returningaccount(id,name),opportunity(id,name)
find {oil} returning account(id,name), opportunity(id,name)

28. Read record fromanotherOrganization

29. CRUD: Create usingJSON Data

30. CRUD: Create usingconvenientinterface

31. CRUD: Read

32. CRUD: Read using convenientinterface

33. Certainobjectsdo not allow DML in Apex
Organizationo=[selectId,NamefromOrganization];
o.Name+='x';
updateo;
yields: Line:3,Column:1DMLnotallowedonOrganization
However,someofthemallowRESTAPIUpdateoperations

34. CRUD: Updateusing JSONData

35. CRUD: Updateusing convenientinterface

36. CRUD: Delete

37. CRUD: Delete using convenientinterface

38. CRUD: Error Handling

39. Access to customREST Services
rel=/services/apexrest/AccoutEnhanced?name=oil

40. Access to customREST Services

41. References
1. http://en.wikipedia.org/wiki/REST
2. http://docs.timdorr.apiary.io/#
3. http://www.slideshare.net/alexeiskachykhin/representational-state-transfer-36518469
4. http://www.slideshare.net/AshishGore3/dt-meetup-django-rest-framework-vs-tasty-pie
5. https://habrahabr.ru/post/38730/
6. https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/

42. Now you should have deeper understanding of
what REST is and which systems can be called
RESTful
Also you should understand how Salesforce
REST API works and which abilities it provides
You can now use Salesforce REST API in your
integration
Summary

43. Q & A? Questions?

46. AND FINALLY:
MAY BE THE FORCE.COM WITH YOU...