Day #8 with Cloud Workflows: calling an HTTP endpoint

Guillaume Laforge
Dec 15, 2020 · 3 min read

Time to do something pretty handy: calling an HTTP endpoint, from your Google Cloud Workflows definitions. Whether calling GCP specific APIs such as the ML APIs, REST APIs of other products like Cloud Firestore, or when calling your own services, third-party, external APIs, this capability lets you plug your business processes to the external world!

Let’s see calling HTTP endpoints in action in the following video, before diving into the details below:

By default, when creating a new workflow definition, a default snippet / example is provided for your inspiration. We’ll take a look at it for this article. There are actually two HTTP endpoint calls, the latter depending on the former: the first step ( getCurrentTime ) is a cloud function returning the day of the week, whereas the second step ( readWikipedia ) searches Wikipedia for articles about that day of the week.

- getCurrentTime:
call: http.get
args:
url: https://us-central1-workflowsample.cloudfunctions.net/datetime
result: CurrentDateTime

The getCurrentTime step contains a call attribute of type http.get , to make HTTP GET requests to an API endpoint. You have the ability to do either call: http.get or call: http.post . For other methods, you’ll have to do call: http.request , and add another key/value pair under args , with method: GET , POST , PATCH or DELETE . Under args, for now, we’ll just put the URL of our HTTP endpoint. The last key will be the result, which gives the name of a new variable that will contain the response of our HTTP request.

Let’s call Wikipedia with our day of the week search query:

- readWikipedia:
call: http.get
args:
url: https://en.wikipedia.org/w/api.php
query:
action: opensearch
search: ${CurrentDateTime.body.dayOfTheWeek}
result: WikiResult

Same thing with call , and args.url , however, we have a query where you can define the query parameters for the Wikipedia API. Also note how we can pass data from the previous step function invocation: CurrentDateTime.body.dayOfTheWeek . We retrieve the body of the response of the previous call, and from there, we get the dayOfTheWeek key in the resulting JSON document. We then return WikiResult , which is the response of that new API endpoint call.

- returnOutput:
return: ${WikiResult.body[1]}

Then, the last step is here to return the result of our search. We retrieve the body of the response. The response’s body is an array, with a first term being the search query, and the second item is the following array of document names, which is what our workflow execution will return:

[
"Monday",
"Monday Night Football",
"Monday Night Wars",
"Monday Night Countdown",
"Monday Morning (newsletter)",
"Monday Night Golf",
"Monday Mornings",
"Monday (The X-Files)",
"Monday's Child",
"Monday.com"
]

So our whole workflow was able to orchestrate two independent API endpoints, one after the other. Instead of having two APIs that are coupled via some messaging passing mechanism, or worse, via explicit calls to one or the other, Cloud Workflows is here to organize those two calls. It’s the orchestration approach, instead of a choreography of services (see my previous article on orchestration vs choreography , and my colleague’s article on better service orchestration with Cloud Workflows).

To come back to the details of API endpoint calls, here’s their structure:

- STEP_NAME:
call: {http.get|http.post|http.request}
args:
url: URL_VALUE
[method: REQUEST_METHOD]
[headers:
KEY:VALUE ...]
[body:
KEY:VALUE ...]
[query:
KEY:VALUE ...]
[auth:
type:{OIDC|OAuth2}]
[timeout: VALUE_IN_SECONDS]
[result: RESPONSE_VALUE]

In addition to the URL, the method and query , note that you can pass headers and a body . There is also a built-in mechanism for authentication which works with GCP APIs: the authentication is done transparently. You can also specify a timeout in seconds, if you want to fail fast and not wait forever a response that never comes. But we’ll come back to error handling in some of our upcoming articles.

Originally published at http://glaforge.appspot.com.

Google Cloud - Community

Google Cloud community articles and blogs

Guillaume Laforge

Written by

Developer Advocate for Google Cloud Platform, Apache Groovy programming language project VP/Chair

Google Cloud - Community

A collection of technical articles and blogs published or curated by Google Cloud Developer Advocates. The views expressed are those of the authors and don't necessarily reflect those of Google.

Guillaume Laforge

Written by

Developer Advocate for Google Cloud Platform, Apache Groovy programming language project VP/Chair

Google Cloud - Community

A collection of technical articles and blogs published or curated by Google Cloud Developer Advocates. The views expressed are those of the authors and don't necessarily reflect those of Google.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store