GenevaGem - Scripted REST Services

Tired of fumbling your way through ServiceNow processor scripts to piece together an integration endpoint? Well it's time to throw out all those hacked up solutions floating around on the community and discover scripted REST services in the Geneva release!

 

First, a bit of history.... 

One of the things that really excited me about ServiceNow way back in 2006 (actually it was officially Service-now.com back then), was it’s open and standard adoption of SOAP web services. I wanted to connect my instance to everything possible since most APIs were still relatively propriety and limited. SOAP was great in its day, and still has some value in integrating with legacy or XML based systems. As RESTful interfaces became more common, ServiceNow administrators were left dealing with a legacy technology. Developers needed to get creative in order to integrate with REST and REST-like JSON systems. Most people working on integrations have had to resort to using custom HTTP processor scripts to meet their needs. These solutions have typically been complex, hard to build, and even harder to troubleshoot. The introduction of scoped apps and restricted APIs in Fuji made working with processors even more of a developer's nightmare.


ServiceNow Geneva release finally brings the platform interface into the modern age of web services. Scripted REST services can, and should, replace most of your custom requirements for processors. It provides a robust and standard integration interface. This feature makes integrating with external systems easier and more secure. 


Here’s a quick summary of why scripted REST services are so important:

  • Full support for application scopes and certified store applications
  • Access to request objects (method, headers, parameters, queries), accessing these components were the biggest challenge with scripted processors
  • Support for multiple API versions allow you to modify method logic without impacting existing users
  • Secure endpoints using standard access control rules and roles
  • Content type negotiation
  • Defined header and query parameters

 

Now for a couple of helpful tips to help you get started:

  • When creating access control rules for REST services, you must specify the type (REST_endpoint) and operation (execute). In a very rare exception for ACLs, the name value doesn’t really matter. Since a single rule can apply to multiple endpoints, the name is only for informational use.

 

  • After enabling version support, you need to create a new version from the related action link on the Scripted REST Service form. 
  • Here you can define the default version as well as copy the methods from an existing version.
  • If you copy an existing version, you'll have a new copy of each method as well as the updated endpoint paths for each.

 

If you’re not already convinced that this is amazing progress, check out these example rest clients running on Node.js and iOS.

With the standard table REST APIs and a few custom REST scripted services, you could potentially build your own front-end application while harnessing all of the powerful core platform features. Now I think we can finally start referring to ServiceNow as an application development platform!

I'm looking forward to see the creative solutions using these new services at the Knowledge16 conference. See you in Vegas!