A web service in salesforce is a piece of software that makes itself available over the internet and uses a standardized XML messaging system. XML is used to encode all communications to a web service in Salesforce. For example, a client invokes a web service in Salesforce by sending an XML message, then waits for the corresponding XML response.
There are mainly two types of web services in salesforce.
- SOAP web services.
- REST web services.
Components of Web Services in salesforce
- SOAP (Simple Object Access Protocol)
- UDDI (Universal Description, Discovery, and Integration)
- WSDL (Web Services Description Language)
Soap web services in salesforce: – SOAP is XML based protocol. It is a platform and language independent. By using SOAP, you will be able to interact with other applications designed in different programming languages.
Rest web services in salesforce: – REST stands for Representational State Transfer, which is an architectural style for networked hypermedia applications, it is primarily used to build Web services that are lightweight, maintainable, and scalable. A service based on REST is called a RESTful service.
Difference between SOAP and REST web services in salesforce
|SOAP stands for Simple Object Access Protocol.||REST stands for Representational State Transfer.|
|SOAP is an XML based messaging protocol.||REST is an architectural style.|
|SOAP permits an XML data format only.||REST permits different data formats such as Plain text, HTML, XML, JSON, etc.|
|SOAP defines standards to be strictly followed.||REST does not define too many standards like SOAP.|
|JAX-WS is the java API for SOAP web services.||JAX-RS is the Java API for RESTful web services.|
|SOAP is a distributed computing style.||REST is a web style (web is also a distributed computing model).|
REST Web Service in Salesforce
REST stands for Representational State Transfer. REST was a term coined by Roy Fielding.
REST is not dependent on any protocol, but almost every RESTful service uses HTTP as its underlying protocol.
Using HTTP Methods for RESTful Services
Features of a RESTful web Services in salesforce: – A Restful web service should have the following features.
- Uniform interface
- Links between resources
The focus of REST web services in salesforce is on resources and how to provide access to these resources. A resource can easily be thought of as an object as in OOP. A resource can consist of other resources. While designing a system, the first thing to do is to identify the resources and determine how they are related to each other. This is similar to the first step in designing a database: Identify entities and relations.
In Rest, we can use any format for representing our resources, as Rest does not put a restriction on the format of representation.
We can use either a JSON format or XML format to represent our resources.
If you are building Web services that will be used by Web pages for AJAX calls, then JSON is a good choice. XML can be used to represent more complex resources.
JSON representation of a resource
XML representation of a resource
Note:-The representation should be capable of linking resources to each other. This can be done by placing the URI or unique ID of the related resource in a representation.
The client and service talk to each other via messages. Clients send requests to the server, and the server replies with a response. Apart from the actual data, these messages also contain some metadata about the message.
An HTTP request has the format shown in Figure 1:
Figure 1: HTTP request format.
<VERB> is one of the HTTP methods like GET, PUT, POST, DELETE, OPTIONS, etc.
<URI> is the URI of the resource on which the operation is going to be performed
<HTTP Version> is the version of HTTP, generally “HTTP v1.1” .
<Request Header> contains the metadata as a collection of key-value pairs of headers and their values. These settings contain information about the message and its senders like client type, the formats client supports, format type of the message body, cache settings for the response, and a lot more information.
<Request Body> is the actual message content. In a RESTful service, that’s where the representations of resources sit in a message.
There are no tags or markups to denote the beginning or end of a section in an HTML message.
Example:- A sample POST request
You can see the
POST command, which is followed by the URI and the HTTP version. This request also contains some request headers.
Host is the address of the server.
Content-Type tells about the type of contents in the message body.
Example:- A sample GET request
There is no message body in this request. The
Accept header tells the server about the various presentation formats this client supports. A server, if it supports more than one representation format, it can decide the representation format for a response at runtime depending on the value of the
User-Agent contains information about the type of client who made this request.
Accept-Encoding/Language tells about the encoding and language this client supports.
An HTTP response has the format shown in Figure 2:
Figure 2: HTTP response format.
The server returns <response code>, which contains the status of the request. This response code is generally the https://en.wikipedia.org/wiki/List_of_HTTP_status_codes.
<Response Header> contains the metadata and settings about the response message.
<Response Body> contains the representation if the request was successful.
Example sample response of post request
In the below image we are getting status code 201. So according to this status code request is completed and an issue has been created on given URL.
Caching is the concept of storing the generated results and using the stored results instead of generating them repeatedly if the same request arrives in the near future. This can be done on the client, the server, or on any other component between them, such as a proxy server. Caching is a great way of enhancing the service performance, but if not managed properly, it can result in the client being served stale results.
A REST web service in Salesforce is stateless and does not maintain the application state for any client. A request cannot be dependent on a past request and service treats each request independently.
The uniform interface constraint is fundamental to the design of any REST web services in salesforce. The uniform interface simplifies and decouples the architecture, which enables each part to evolve independently.
Links between resources
A resource representation can contain links to other resources like an HTML page contains links to other pages. The representations returned by the service should drive the process flow as in the case of a website. When you visit any website, you are presented with an index page. You click one of the links and move to another page and so on. Here, the representation is in the HTML documents and the user is driven through the website by these HTML documents themselves. The user does not need a map before coming to a website. A service can be (and should be) designed in the same manner.