SOAP vs REST

SOAP

• Simple Object Access Protocol

• Web Service API

• Synchronous request response architecture

• XML

• Standards based

• WSDL (Web Service Description Language) (a package to define all the methods) needs to be downloaded and saved to the server.

  • The structure of the web services that clients can call

  • An XML file describing the endpoints.

  • A contract between the server and the client

  • Also defines the operations that Salesforce supports

  • And a definition of the data that will be passed back to the client

• System to system

• State maintained

• Supports gZip compression

• Built in security

  • OAuth or Session ID (OLD)

• Can build Custom SOAP Web Services

• Standard Salesforce WSDL

• SOA (Service Oriented Architecture) Callout (eg bring data into external systems)

  • Synchronous

• Web Service API

  • Anything referring to Web Service relates to SOAP.

• Custom Web Service is inbound

  • Your client application submits a service request to the Web Service via the API

• Callouts are outbound.

  • Callouts require a remote site setting.

  • The domains you want to allow communication to.

• Layers

  • Application Layer

    • HTTP, SOAP, SSL, FTP etc

  • Transport Layer

    • TCP, UDP

  • Internet Layer

    • IP, ICMP

  • Link Layer

    • Ethernet, DSL, PPP etc

  • Gee this is all stuff I learned in my university days in the early 90s

• Process

  • Insert records into Salesforce

  • Convert CSV data to XML

  • Send request for 200 records

  • Salesforce parses the request

  • Saves the records to the database

  • Return the success or failure response message to the client

  • This all happens synchronously.

  • Individual records be rolled back if exceptions.

    • Eg 198 records may be successful, 2 may have errors.

• First call passes the username and password

  •  Typically you will need to append the security token to the password unless your IP address has be added to the Org.

  • All subsequent calls pass the session ID that is returned from the successful authentication

  • See Documentation https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_calls_login.htm

Enterprise WSDL

• Strongly Typed

• For a specific org - has all of the customisations in that org

• Changes if the org changes (eg custom fields added)

Partner WSDL

• Loosely typed

• Can be used against any org (eg used by partners)

• Static - only changes based on API version?

REST

• Representational State Transfer

• Stateless

• Synchronous

• Higher performance

• URI over HTTPS

• “lower level on the networking stack” (dunno if it’s important, but it was repeated many times in a 2011 video)

• XML or JSON

• REST has in-built discovery of the available methods / endpoints

• Lightweight

• Security usually via OAuth

  • Old via Session ID

• Standard Salesforce endpoints on every object (Standard and Custom)

• Web service implementations

  • Expose your own APEX classes as REST Endpoints

• GET POST DELETE PATCH PUSH

• Process

  • Request header contains authorisation

    • OAuth Token or Session ID retrieved from authorising via username password and token authentication

  • The URI is the address it goes to

  • The data is stored in JSON

  • The http Method is POST eg

  • The http Response is produced by the server and returns JSON data

    • Can receive response in XML with an ACCEPT header

• Bulk API uses REST See https://tddprojects.atlassian.net/wiki/spaces/SF/pages/1310425107

Synchronous vs Asynchronous

• Sync

  • Eg a transaction

  • Wait for a reply

  • Within the Salesforce limits

• Async

  • Check back later if it’s done

Callouts

• Ajax Toolkit (see https://tddprojects.atlassian.net/wiki/spaces/SF/pages/1310425188 also)

  • Callouts via Apex with a Visualforce Controller

  • VF page requests data from VF Controller.

  • Controller does the callout to get the data.

  • Look wow, this would have been mindbreaking revolutionary stuff back in 2003 but now it’s just something you do regularly.

• SOAP callouts

• REST callouts

• See https://tddprojects.atlassian.net/wiki/spaces/SF/pages/1310556236

Security

How to encrypt data and authenticate between systems

SSL and TLS is the handshake that takes place between a client and a server. It doesn’t do the encryption itself (really?) it agrees on the shared secret and encryption that is going to be used.

SSL

• Secure Transport over HTTP (HTTPS)

  • Implemented at the Application Layer

  • Network Segments are encrypted end-to-end in the transport layer (TLS)

• One way SSL is enabled by default.

  • Salesforce calls out to another application

  • The application sends back a certificate

  • Salesforce verifies the certificate

• Two way SSL needs self-signed or CA-signed certificates

  • Both the client and server present a certificate to prove their identity to the other party

• For the exam only, not reality now with many different options available…

  • Apex code ignores profile based security.

  • Can respect or ignore record level security.

• Two way SSL is mutual authentication

Inbound

• External system connecting to Salesforce

• Create separate user and give them a separate profile

• Restrict that profile to only the fields / objects required to be used by the external system.

• Uses the OAuth username-password flow or SSO.

TLS

• Transport Layer Security

• You upload your certificate to Salesforce

• You can download salesforce client certificate to authenticate on your web server.