Prismatic leads in satisfaction for embedded iPaaS!

Prismatic
Blog
HTTP Methods for SaaS Integrations
Integration Development
Integration Fundamentals

HTTP Methods for SaaS Integrations

HTTP methods are essential to SaaS integrations. Let's dig into a little history and then see how their usage varies based on the type of API.
Nov 11, 2022
Bru WoodringMarketing Content Writer

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
<html>
This is a webpage.
</html>

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
{
"id": 1,
"jsonrpc": "2.0",
"method": "listCustomers",
"params": ["u6f6igwe3"]
}

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
<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope"
SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<SOAP-ENV:Body xmlns:m="http://www.example.com/">
<m:GetCustomer>
<m:CustomerID>HVT076236</m:CustomerID>
</m:GetCustomer>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

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
query {
getCustomer(id: "87983") {
id
custname
user {
username
fname
lname
}
}
}

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.

Want to learn more about API integrations?
Download our API Integrations Guide to see what an API integration is and learn how it works.
Get the guide
Share this post
Headshot of Bru Woodring
Bru WoodringMarketing Content Writer
Bru brings 25+ years experience bridging the communications gap between devs and business users. He has much first-hand knowledge of how to do integrations poorly.
Get a demo

Ready to get started?

Get a demo to see how Prismatic can help you deliver integrations fast.