Implementing API services using a scoped Application   

Introduction: A well-known platform makes it easy to write workflows involving Service desk operations.  A scoped application is a custom plugin on that platform that implements a specific functionality that is usually not found on the platform. Most applications are like self-contained micro-services with their own set of tables, scripts, and user interface. This article tries to elaborate on what it takes to implement APIs as part of those offerings from a scoped application.  

Description: The platform mandates that the logic and data are packaged in artifacts that conform to pre-existing entities. There are entities for scripts, UI pages, and even custom tables but there is no description for implementing API services. APIs are powerful because they enable clients to be across the wire while self-containing all logic. Micro-services and their popularity are a demonstration of the power of APIs especially when the callers are mobile applications and personal desktops.    

API logic is authored in jar files. But there is no platform entity to register jar files other than the MID server Jar files which store specific rules. The scoped application can import APIs from the platform by bringing in dependencies many of which are jar files. The pom.xml file for building the scoped application can list these dependencies but the target of the build is usually a zip file of artifacts that the platform knows how to import. This calls for the API to be written in a scripting language.   

Both JavaScript and PHP allow API servers to be written such that they can be shipped as text files which is an artifact that can be registered to the platform alongside the others in a scoped application. They require to be started and monitored but usually the traffic to a scoped application does not need to concern itself overly with scalability and performance as much as it must be secure.  

The ways to secure APIs are usually independent of the implementation language because most usually follow the REST convention. The use of authorization headers, encrypted requests, API keys, and tokens make these endpoints securable. The logic of the API itself is usually conforming to the HTTP verbs to create, update, delete and list semantics. There might be some operational APIs such as to get statistics or for usage information or to populate metrics or to indicate that the API server is alive, but these are usually few. The bulk of the APIs is organized around the actions associated with those resources. These resources are also as custom as the scoped application. Platform resources are usually having their own APIs, so it is advisable to not write anything that pertains to the platform.  

A scoped application that collects feedback in terms of source UI page and corresponding user rating can, for example, allow a programmability aspect to the feedback collection table with the logic that makes it easy to query that table or for correlation with platform tables and UI pages.  The ability to enhance the logic in a scoped application and providing a programmability aspect that improves automation, scripting, and invocations via external scripts, applications, and services will tend to make the application more popular.  

Conclusion: It is possible and easy to implement API services in a scoped application where the application is dropped just like a tar ball and written using JavaScript.  

Reference: for sample scoped application discussion: https://1drv.ms/w/s!Ashlm-Nw-wnWyBYIKC6_TDLdliTd?e=NEldrF