Important Update: Some Community URL Redirects are Under Maintenance. Learn More. .

cancel
Showing results for 
Search instead for 
Did you mean: 

Getting Started - Archer API Basics

Anonymous
Not applicable

API - You've probably heard or seen the acronym at some point in the past, but have you ever wondered what it stands for or how can it help you maximize your Archer deployment? The Archer API is a powerful tool that can help you manage, extend, and maximize your Archer deployment. Let's dive into the basics.

 

API stands for Application Programming Interface. Archer currently offers two flavors of API for you to choose from. There's the Web Services, or SOAP, API as well as the the REST API. The SOAP API has been offered with Archer for quite some time, with the REST API being introduced later in the 5.x product line. Both are available in all versions of the 6.x product line.

 

Why does Archer have two APIs you ask? Well, they are different in both the way the behave and the way you interact with them. One is newer technology (REST) than the other, and they currently have different feature capabilities because of this. While we are in the process of deprecating the SOAP API in favor of all REST, that will be a multi-release process with no date set yet on official SOAP deprecation, so rest easy on that for now and into far long term.

 

Let's look at how they differ. To start, SOAP stands for Simple Object Access Protocol while REST stands for REpresentational State Transfer. In simpler terms, the former is a protocol while the second is an architectural style. For more details on that, please visit this informative post: SOAP vs REST Differences - Stack Overflow 

 

From and Archer perspective, they differ in a couple ways. Primarily in what they accept as input, and how they return output. The SOAP API generally requires an XML input or pre-formatted variables passed directly into an API method, such a CreateDomainUserSessionFromInstance(string userName, string instanceName, string password, string usersDomain). This is vastly different than the REST API, which for the same action would require an HTTP POST sent to the http://RSAarcher/api/core/security/login controller with specifically crafted HTTP Request Headers and a JSON formatted HTTP Request Body. We'll be covering more details on exactly how you call these in the next blog.

 

If you've worked with APIs before, you're probably now wondering how you get your hands on them. The first step is to ensure that they are setup properly. For that, you need to make sure that both the "/api" and "/ws" folders underneath your Archer website are set to allow Anonymous authorization only. In addition, the "/api" folder needs be an application. For more details on this, please refer to the RSA Archer 6.2 Security Configuration Guide.

 

pastedImage_3.pngpastedImage_2.png

 

 

Finally, we'll touch on the feature differences between the two APIs. The following two screen shots are from past Charge presentations done by James Griffith‌ and Jeff Letterman‌, and do a good job of highlighting the main differences.

 

pastedImage_4.png

Source: Tool Time - The Power of the RSA Archer Web Services API and REST API.pdf 

 

pastedImage_5.png

Source: The New Archer REST API_A Practical Introduction.pdf 

 

 

In our next blog post, we will be diving into code examples around authentication to both APIs as we start making use of them, so stay tuned! And go vote on the  poll so we know what language you all want us to demo/provide API code in!

1 REPLY 1

VictorParrott2
Contributor II

Excellent info Scott, I will be using the REST API.

Thanks!

 

FYI, I couldn't add a comment with the bottom button.  I used the comment link next to the Like link at the top of the page.