As a .NET application, Exago BI supports three types of APIs: .NET, SOAP, and REST. While SOAP (Simple Object Access Protocol) once rivaled REST (Representational State Transfer) as the most commonly implemented web service API platform, its fan base has long since dwindled. These days, REST is so popular that .NET applications hosting Exago BI have been known to implement a REST API even though they have full, unmitigated access to our .NET code. The reason for this is that there are sometimes extenuating circumstances where REST is really the best option, even for .NET shops. These circumstances are outlined below.
Scenario #1: Your Application is Running a Different Version of .NET
If your application and Exago BI are running different versions of .NET, they’re effectively speaking different languages. Rather than risking exceptions and failed method calls, set up a REST layer to keep your applications in sync.
Scenario #2: Your Application is Running on a Different Machine
If for security reasons you’re serving your host application from a different machine than you use to serve Exago BI, bridging that architectural gap can be a challenge, even if both applications are running the same version of .NET. A REST API will, in this case, serve as a central command platform from which to manage both applications and their interactions with one another.
Scenario #3: You Have Other Applications in Your Application Layer
In the event that you are managing multiple applications simultaneously and at least one of them is not written for .NET, it’s often more efficient to unite them under one API than to find a way of juggling disparate APIs. In this case, even if your host application is written for .NET, REST’s ubiquity on the Web makes it highly likely to be supported by all the web applications under your purview. In this case, a REST API is the way to go!
For more information about Exago BI’s REST API support and implementation, visit our Knowledge Base.