Rest API for custom scoped application

[MalakaSilva]

When building a custom application, suppose we have a set of records where some operations involve more than simply updating fields.

For example, an operation may require server-side calculations, validation of conflicts, generating a resolution plan, or potentially creating/updating related records as part of the same operation.

In such a scenario, would you consider it a good practice to expose the functionality through a custom Scripted REST API and have clients go through that API, rather than allowing them to perform the corresponding operations directly through the Table API?

The reasoning would be that the Scripted REST API becomes the controlled business-logic layer, where the necessary calculations, validations, related-record processing, and access checks are handled centrally.

I'd also appreciate your advice on whether there are any ServiceNow APIs or platform capabilities that are specifically restricted to certain editions or licensing tiers and therefore should be avoided when designing a generally distributable application.

[martinvirag]

I would never allow to do an operation via table api, because you don't have much control over it and in a case of a potential data leak you basically allow bad actors to directly call the table.

Scripted REST API is perfect as you have mentioned as it only communicates as much data as you want. 

If you would like to do creating or updating I would also consider an alternatie approach the import set api.

you can create an import set, build up the transform maps or RTEs and then insert.

The benefits here are: decouple the actual transform, hence you have better performance. the Imports are already logged, no need to do custom logging there, plus in a case of a data leak, the bad actor  can directly acces only the import set table and have no knowledge of the underlying tables at all

[Tanushree Maiti]

Hi @MalakaSilva 

As an Architect, I generally prefer and recommend  Scripted REST APIs over Table APIs, especially for integrations that require better control, security, traceability  and error control even after knowing Scripted rest API's Maintenance and Development Overhead is more than table API.

Disadvantages of Using Table APIs

1. Limited control over data
With a Table API, users or systems on the other end may have the ability to directly create or update records without going through specific business validations or controls. For example, in one of my client projects, an end user accidentally created test incidents directly in the production environment.

2. Limited traceability
If the integration details are not properly documented, especially in an older instance, it can be difficult to determine exactly where a request originated or which integration/process created or updated a record.

Although you may be able to identify the integration user, that alone may not provide enough information to determine the actual source system, process, or business context behind the transaction. This can make troubleshooting, auditing, and root-cause analysis more challenging.

3. Performance considerations
If an integration grows significantly in terms of volume or complexity, frequent or uncontrolled direct access to tables can potentially impact system performance. With a Scripted REST API, you have greater control over how requests are processed and can implement appropriate validations, filtering, logging, authorization, monitoring, and other safeguards.

4. Error Handling 
With a Scripted REST API, developer can explicitly implement appropriate validation and conditional error handling for scenarios such as invalid data structures, missing or incorrect parameters, authorization issues, and processing failures.

For these reasons, I generally prefer Scripted REST APIs when we need stronger governance, security, validation, auditability, and control over how data is accessed or modified.

Table APIs can still be appropriate for simple and well-controlled use cases, particularly when direct table access is acceptable and proper governance, security, and documentation are already in place.