HTTPCaller and Google Calendar API: POST, PUT, PATCH, DELETE

Introduction

This article demonstrates and describes POST, PUT, PATCH, and DELETE requests using the Google Calendar’s API. These methods are intended to make changes or updates to the server, so they should be used with caution. In the following exercise, we will create a new event, make updates to that event, then finally, delete the event from the calendar. 
 

Requirements

• A free Google email account

POST: Make a New Event

To make a new event, we can use a POST request to update the server. POST requests, in addition to a URL, often require a request body and request-headers. Data that is intended to be accepted by the server is contained in the request body. The type of data contained in the body is specified in a header field.

POST requests are not idempotent nor safe. Multiple requests made after the initial call will make changes to the server state. 

A POST request points to the URL that should handle the request body. The URL can accept or redirect the request as needed.

For example, if you create an event using POST, an identical subsequent request will create another duplicate request. 
 

Use a POST request to make a new Google Calendar event with a location, time, description, and guests.

1. Consult the documentation
Find the URL and parameters at the Events: insert page. 



Any information we might want to include about the event is sent in the request body. In this case, the request body is an Events resource JSON body. Included in the documentation is information about the allowed properties.



The Events Resource page supplies a template of an event object that can be copied, pasted and edited in your own requests. 



2. Build the Request
Back in the workspace, first set the HTTPCaller’s HTTP Method to POST. The request URL will also need to be amended to reflect the URL from the documentation. Replace the calendarId path parameter with the target calendar’s “id” value. Remove any query parameters still remaining from previous requests.



It’s possible to send different types of data with a POST request using the parameters on the HTTPCaller. The data to upload can be string value, a file, or customized combinations. When sending a POST request, a Content-Type header tells the server the type of data contained in the request body. HTTPCaller has a drop-down list of commonly used values and it also can be customized with a text or attribute value. 

We will type in the properties of our new event, so we can use the “Specify Upload Body” as our Upload Data. The request body, as seen in the example above, is JSON. Specify “JSON (application/json)” as the Content Type header. 



The Upload Body is where the event properties are contained. Working off the properties page and example provided by the documentation, fill in the JSON key values with the details of your event. Guests can be added provided they have access to the event. 



3. Run the Workspace
With Feature Caching enabled, run the workspace to the HTTPCaller. Use the green magnifying glass to view the results in Visual Preview. With a successful call, the _response_body will contain the system properties of the new event in addition to those that we sent with the request. Copy the event’s “id” property to your clipboard, we’ll use it in the next request. 



4. View the event in the browser. 
The API response is proof enough to let us know we’ve created an event, but let's confirm in the browser. Open up your Google Calendar in the browser and find the newly created event. Any changes you make using in the browser will be reflected in future HTTP calls, and vice versa. 

PUT: Update an Event

Idempotency is the key difference between a PUT and POST request. A PUT request is idempotent: making the same PUT request repeatedly will not result in repeated actions. 

A PUT request URL is more specific than a POST request URL. The URL indicates the specific resource location to store the request body. The request can be accepted or rejected, but not redirected elsewhere.

For example, if you create an event using PUT, an identical subsequent request will not create another duplicate event, but it will replace the event at that resource location.

Google Calendar API uses a PUT request to update an event. Using request body properties, we will use the next request to change the start time of our event and notify our guests. 

1. Consult the Documentation
The Events: update documentation is similarly structured to the Events: insert page we consulted in our last request. Most of the properties that can be created with a new event and modifiable using a PUT request. 



2. Build the Request
In the HTTPCaller, change the Request Method to PUT. Replace the Request URL with the that from the documentation and replace the path parameters with your calendarId and eventId (from the previous request). When a URL becomes too long to manage in the form, use the drop-down menu to select the Text Editor to construct the parameters.



For the Request Body, all existing event properties must be sent with the request, along with our updates. A PUT request replaces the resource at the URL, so any properties that are not included with the request will be lost. In this case, the event ‘start’/‘end’ time will be changed to 7:00 and end at 15:00, 2 hours earlier than the original event. I’ll also change the title and summary for a PUT event. 




3. Run the Workspace
A successful request returns the event resource in the response body with updated properties. Checking your calendar, you’ll see it is now scheduled 2 hours earlier. Because we set sendUpdates property to “all”, the attendees will also be notified of the change. 

PATCH: Updates an Event Properties

Whereas PUT replaces a resource at a URL, a PATCH request can update individual properties of that resource. The specified properties will be updated with new values, but unspecified properties will remain unchanged. We will change the location, add an external link, and update the title. 

1. Consult the Documentation
Events: Patch is structured similarly to the POST and PATCH documentation.



2. Build the Request
The Request URL remains the same as the previous PUT request. Change the HTTP Method to PATCH. In the Upload Body, delete any properties we are uninterested in updating. 



3. Run the Workspace 
Run the workspace and view the response body or your calendar in the browser. The event will be updated with a new title, location and include a source URL. 

DELETE: Delete an Event

A DELETE request removes a resource from the specified location. Use this request to delete the event. Use caution with this method, as often the deletion is permanent. 

1. Review the Documentation
The resource URL is constructed the same as the PATCH and PUT requests. Below, parameters to accompany the request are listed. Notably, there are no properties for a request body listed for a DELETE request. 



2. Build the Request
In the HTTPCaller, the Request URL can remain the same from the previous request. Change the Request Method to DELETE. Remove all remaining parameters, headers or body left in the transformer. 



3. Run the Workspace
Run the workspace to the HTTPCaller. No response body is returned, but a Status Code: 204 (No Content) lets us know the resource is no longer there and the event was successfully deleted. To confirm, check your calendar in the browser, the event will no longer be there. 



This concludes the HTTP request exercises with the Google Calendar API. Using the knowledge of how to use each request method with the HTTPCaller, try building a workspace that creates a recurring event in your calendar. Or, sync events across applications by connecting to another API in the same workspace. The HTTPCaller is especially powerful when used in tandem with FME Server where you can automate and schedule your workflows. 

Keep reading about the HTTPCaller: 

• How to Access an API using the HTTPCaller
• Making a GET Request with HTTPCaller
• Leveraging the Box.com Web Service with FME
• Getting Started with FME and the Web

Data Attribution

The data used here originates from data made available by Google Calendar API . Please review the terms of service and usage limits before using the API in your projects.