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.
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.
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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.