One of the unsung features in the Automated Test Framework is that you can use it to test your Scripted REST APIs. I’m a fan of having as much robotic coverage as possible, so backstopping API development with tests is a good thing. Let’s look at how to do that. I will use an example of a relatively recent API that I developed, the commenting system on this very blog. I’ll create a test that:
Scripted REST API
In an interesting coincidence, I recently had to solve this issue in my own Travel Tracker app (as seen on a number of Live Coding Happy Hour episodes). Just today, someone in the Developer Program asked the same thing so I thought I would document it for posterity. What happens when an incoming connection you don’t control (such as a webhook) isn’t using application/json or application/xml as the Content-Type on the HTTP transaction?
tl;dr If you use Stream Writers in your Scripted REST API, explicitly set the HTTP status or it won’t work the way you expect. Muuuuch longer version This is based on a problem a coworker (and sometimes cohost) saw yesterday. He set up a Scripted REST API that returned about 200 records in a JSON object, total payload was ~36k. When loaded in the browser directly, it worked fine. Consumed via either curl or a different instance with a REST message, nothing ever moved down the wire.
YouTube video: https://www.youtube.com/watch?v=8_yHYAPDpvw The live coding team: josh.nerius, ctomasi This week, we returned to the topic of OAuth and learned how to generate OAuth tokens per user instead of per REST Message/Method. When calling some APIs, sharing a single token between every user in ServiceNow is not always appropriate and instead we want each user to have their own token. Examples: Calling the Dropbox API and interacting with the currently logged in user’s files Calling the GitHub API and forking repositories on behalf of the current ServiceNow user Video Index 00:00 - Intro
In Inbound OAuth Auth Code Grant Flow Part 1 - Getting Started with Postman, we configured Postman to use the new OAuth functionality available in Istanbul. In this post, we’re going to implement this functionality in a real web application. A Few Notes About the Node.js “My Work” App The ServiceNow Interfaces team has released a series of sample applications that demonstrate the use of ServiceNow APIs. These apps are available on GitHub here, and are great resources for learning more about ServiceNow APIs and getting some example code up and running quickly.
YouTube video: https://youtu.be/3GqFrhQD8MM The Live Coding Team: dave.slusher, ctomasi, josh.nerius In this episode, we begin working with Dave’s Travel Tracker application and integrating with the FlightAware API to get real time status information about commercial airline flights. We do outbound integration with REST Messages and also create a Scripted REST API to accept status information via the FlightAware webhook. Video Index 02:11 - Introduction to Travel Tracker 04:47 - Introduction to FlightAware API 07:27 - Showing the Script Include with API calls 09:38 - Looking at the payload of the Flight Info webhook call 11:27 - Building the Scripted REST API 29:16 - Saving the API information back to the records 48:17 - Registering the Scripted REST endpoint with FlightAware 53:08 - Setting the alert for our flight 58:43 - Closing comments Useful Resources
In the developer program, we have a program where on many Fridays a group of us get together and broadcast ourselves working through code problems. If you’d like to get notification of when we go live or post a new episode, you can subscribe to our YouTube Channel. Here is a list of all the shows to date, grouped by subject matter. Note that episodes may contain multiple subjects and may appear in multiple lists.
One of the new features in Geneva is the ability to write Scripted REST APIs. These take the place where Processors were used previously but have a richer feature set and more flexibility. Scripted Rest API basics When you create a new API inside the Studio environment, you define a name for it and an API ID (which will default to the name but can vary independently). Based on your currently selected application scope, it will automatically choose that application and namespace which corresponds to your scope identifier.