HTTP methods (also called HTTP verbs) are essential to SaaS integrations. But before these methods were used for integrations, they were developed for web browsers. Initially used for displaying web pages, these requests became essential for submitting forms and doing the many other functions necessary for today's media-heavy websites.
In this post, we'll be focusing on HTTP methods as used for SaaS integrations.
History of HTTP methods
The first version of HTTP was extremely simple and only used the GET method. Here's a browser request circa 1991:
GET /webpage.html
And here's the corresponding result:
123
In 1994, the first full HTTP specification included GET, HEAD, and POST methods. In 1999, the HTTP 1.1 specification added PUT, TRACE, DELETE, OPTIONS, and CONNECT. PATCH made it on the list in 2010.
In addition to these, WebDAV (web distributed authoring and versioning) has defined more HTTP methods. However, these methods focus on remote file editing and manipulation and are not commonly seen with SaaS integrations.
What methods do SaaS integrations use
As noted, we have the following methods as part of the most current HTTP specification:
- CONNECT: set up a tunnel with the resource
- DELETE: remove the resource
- GET: request data from a resource
- HEAD: request data, but without a response body (just the HTTP headers)
- OPTIONS: describe communications option for resource
- PATCH: partially modify a resource
- POST: create or fully modify a resource
- PUT: create or fully modify a resource, but idempotently. If you invoke the same
PUT
request two or more times, the first request will update the resource and additional requests will overwrite the resource with exactly the same data. - TRACE: test the path for the resource
As you can see, five of these methods (DELETE, GET, PATCH, POST, and PUT) interact with a resource to support CRUD (create, read, update, delete) functions. Unsurprisingly, those are the HTTP methods commonly used with SaaS integrations to transport data via HTTP. But the type of API an integration uses determines which methods are supported.
What do APIs mean for HTTP methods?
In theory, you could set up an API to accept any HTTP request method (or even to use custom methods that are not a part of the current HTTP specification). In practice, different types of APIs implement HTTP methods differently (but consistently for each type of API). Let's look at some standard types of APIs and see how each one uses HTTP methods.
REST APIs and HTTP methods
A REST (representational state transfer) API uses all five standard HTTP methods: GET, DELETE, PUT, PATCH, and POST. These methods may be used with numerous API endpoints, each endpoint tied to a single resource (data collection or data record). For example, https://sampleapi.com/customers
is the endpoint for working with customer records.
Here are a couple examples of what REST requests look like, using GET and POST.
To get a list of customers from our sample REST API, we can use the following:
GET https://sampleapi.com/customers
To create a new customer via our sample REST API, we can use the following:
POST https://sampleapi.com/customers
You'll notice that the method used makes sense with the operation performed. That is, the GET request receives some data, while the POST request sends some data. While sensible relationship between methods and actions is true for REST APIs, it is not true for many other APIs.
RPC APIs and HTTP methods
RPC (remote procedure call) APIs don't make resources available like REST APIs. Instead, requests to RPC APIs call remote procedures, and the remote procedures perform the necessary functions against the underlying data.
As a result, RPC APIs don't need to use the different HTTP methods because the methods don't determine the action performed; that's the literal function of the remote procedure.
RPC APIs usually implement POST for all HTTP requests.
To get a single customer from our sample JSON-RPC API, we can use POST with the following:
123456
SOAP APIs and HTTP methods
SOAP (simple object access protocol) APIs are the direct descendent of earlier RPC APIs. They, like RPC APIs, focus on calling remote procedures to perform functions rather than working with resources directly (as REST APIs do).
SOAP APIs use a single HTTP method for all requests: POST.
To get a single customer from our sample SOAP API, we can use POST with the following:
12345678910
GraphQL APIs and HTTP methods
GraphQL APIs are quite different in function from REST, SOAP, and RPC APIs. GraphQL APIs also implement HTTP methods differently, supporting both POST and GET.
Like SOAP and RPC APIs, however, GraphQL APIs each have a single endpoint.
To get a single customer (and related user data) from our sample GraphQL API, we can use POST with the following:
1234567891011
We could also query for a single customer using GET, but we would need to include all of our query parameters in a single string. Because this can make the HTTP request grow long enough to trigger a 414 error (Request URI too Large), most implementations of GraphQL use POST as the standard method for HTTP requests.
Conclusion
HTTP methods are essential for SaaS integrations that connect over HTTP. Different types of APIs implement the methods differently, but each API that accepts HTTP as the transfer protocol must also use at least one HTTP method for HTTP requests.
The methods supported by different API types are as follows:
- REST API: GET, DELETE, PUT, PATCH, and POST.
- RPC API: POST
- SOAP API: POST
- GraphQL API: POST and GET
For more content on HTTP methods and other integration topics, check out our guide to API integrations.