Scripted REST API question

[Viji Rohan]

Hello, 

I have a question on using the same scripted rest api for two different tables by creating separate resources. I have a requirement to ingest vulnerability data into ServiceNow from an external source. The data could be for VRM or AVR (Application vulnerability). The tables for VRM & AVR are different. Instead of creating two scripted REST endpoints, is it a good practice to use the same scripted REST as the external system is the same. I had always created a separate scripted REST API in the past like Incident, change etc., Need some inputs please if there are any drawbacks of using the same scripted REST for two different purposes. The benefits expected out of this is specific to my organization wherein we have an intermediate platform within the intranet (a kind of proxy api or jump box) to route the requests to ServiceNow. Every REST API endpoint needs to be onboarded to this platform which is expensive in time, effort and ongoing maintenance. Instead of two endpoints being onboarded, we are looking to have one endpoint which can combine two requirements. The consuming application is the same in this case to so that there is no issue in the authentication being shared.

I have also tagged this comment in this post:

My experience with Scripted Rest APIs and some goo... - ServiceNow Community

[Amitoj Wadhera · Accepted solution]

Hi @Viji Rohan ,

Using a single scripted REST API endpoint for both VRM and AVR tables in ServiceNow is feasible and can reduce maintenance overhead. Here's a streamlined implementation approach:

Benefits

• Reduced Maintenance: One endpoint to manage.
• Simplified Security: Unified authentication.
• Cost Efficiency: Less onboarding effort.

Drawbacks

• Increased Complexity: Conditional logic for handling different tables.
• Error Handling: More complex.
• Scalability: Future changes could complicate the endpoint.

Implementation Strategy

1. Request Parameterization: Use a parameter to distinguish data types (e.g., data_type).
2. Modular Design: Separate functions for VRM and AVR logic.
3. Comprehensive Documentation: Clearly document the API.
4. Robust Error Handling: Implement detailed error handling and logging.
5. Extensive Testing: Test all scenarios thoroughly.

Example Script:

(function process(request, response) {
    var requestBody = request.body.data;
    var dataType = requestBody.data_type; // 'VRM' or 'AVR'

    try {
        if (dataType === 'VRM') {
            handleVRMData(requestBody);
        } else if (dataType === 'AVR') {
            handleAVRData(requestBody);
        } else {
            throw new Error('Invalid data type specified.');
        }

        response.setStatus(200);
        response.setBody({ result: 'Success' });
    } catch (error) {
        response.setStatus(500);
        response.setBody({ error: error.message });
    }

    function handleVRMData(data) {
        var vrmRecord = new GlideRecord('vrm_table');
        vrmRecord.initialize();
        vrmRecord.setValue('field1', data.field1);
        vrmRecord.insert();
    }

    function handleAVRData(data) {
        var avrRecord = new GlideRecord('avr_table');
        avrRecord.initialize();
        avrRecord.setValue('field1', data.field1);
        avrRecord.insert();
    }
})(request, response);

This approach efficiently manages both VRM and AVR data with a single endpoint, simplifying your API management while maintaining clear separation of logic within the script.

If you find my response helpful, please consider marking it as the 'Accepted Solution' and giving it a 'Helpful' rating. Your feedback not only supports the community but also encourages me to continue providing valuable assistance.

Thanks,

Amitoj Wadhera

[Viji Rohan]

Hi Amitoj,

Thanks for your response.  This helped me to look into it further. I feel separate endpoints are better due to the reduced complexity.