Scripted REST APIs good practices
Summarize
Summary of Scripted REST APIs Good Practices
This guide provides best practices for designing and implementing scripted REST APIs in ServiceNow, ensuring consistency, reliability, and security for API clients. Following these standards helps you create APIs that are easy to use, maintain, and evolve without disrupting existing integrations.
Show less
Follow REST API Conventions
- GET operations should only retrieve data and never modify it.
- POST operations create new records without modifying existing ones.
- PUT and PATCH operations modify existing records.
- DELETE operations remove records.
Adhering to these conventions ensures a predictable and standardized API interface for clients.
Use Versioning to Control API Changes
Implement versioning to introduce new functionality while preserving existing integrations. When making significant changes, create a new API version rather than altering a published one. This approach allows existing clients to continue using the old version until they are ready to upgrade. Encourage clients to specify the API version explicitly, and use optional parameters to add new behaviors without breaking compatibility.
Return Informative HTTP Status Codes
Use appropriate HTTP status codes to clearly communicate the outcome of each request:
- 200: Request completed successfully.
- 201: A record was created successfully.
- 204: A record was deleted successfully.
- 40X: Client errors such as bad requests (e.g., 400) or not found (e.g., 404).
- 50X: Server errors indicating issues processing the request.
Provide Useful Error Information
Include clear, descriptive error messages along with status codes to help clients quickly understand and resolve issues without needing to consult documentation. Utilize preconfigured error objects or customize error responses to deliver meaningful feedback, such as specifying when a requested record does not exist.
Enforce and Test Access Controls
Ensure robust security by enforcing authentication and authorization. Use the GlideRecordSecure API to apply data access controls based on the requesting user. Require stricter access permissions for operations that modify data (POST, PUT, DELETE) compared to read-only operations (GET). Thoroughly test all access controls before releasing the API.
Build Tests to Verify Functionality
Develop repeatable tests to validate your scripted REST API’s functionality, response codes, headers, body content, and authentication requirements. Automated testing tools such as Postman can facilitate this process. Testing helps maintain API reliability and prevents regressions during updates or version releases.
Follow these guidelines when designing and implementing scripted REST APIs.
Follow REST API conventions
Use REST API standards to provide a consistent and easy to use interface for clients. REST API conventions define specific behavior for each type of method. Use the following guidelines as a starting point for designing your API.
- GET operations only query data. A GET request should never modify data.
- POST operations create new records but do not modify existing records.
- PUT and PATCH operations modify existing records.
- DELETE operations destroy records.
Use versioning to control changes to your API
Use versioning to implement new functionality and avoid breaking existing integrations. When you introduce significant functionality changes to your API, create a new version of the API first. Do not introduce behavior that will break existing integrations in a published version.
Using versioning allows you to implement significant changes to your API without breaking existing clients. You can then release the new version of the API for new clients while allowing existing clients to upgrade at their own pace.
Encourage clients to use a version-specific API, or configure the API without a default version to force clients to specify a version. You can also make new, optional behavior available by adding an optional parameter to an existing version.
Return an informative HTTP status code
Return a status code that informs the requestor of the success or failure of the request. Return an HTTP status code that helps the client understand the result of the request. Use the following guidelines for common status codes.
| Status code | Description |
|---|---|
| 200 | Indicates that the request was completed successfully. |
| 201 | Indicates that a record was created successfully. |
| 204 | Indicates that a record was deleted successfully. |
| 40X (401, 404) | Status codes in the 400 range indicate a client error, such as 400 for invalid request syntax. |
| 50X (500, 503) | Status codes in the 500 range indicate that a server error occurred. The client request may have been valid or invalid, but a problem occurred on the server that prevented it from processing the request. |
Return useful error information
Provide the client with enough information in error messages to allow them to understand the problem without having to refer to your API documentation. An error response should include a helpful error message, as well as an error status code.
For example, when a client queries a record that does not exist, you can return the error message "The specified record does not exist. Ensure that a record with the ID of <id value> exists in the application." along with a 404 status code.
The scripted REST API feature includes several preconfigured error objects you can use for commonly-encountered errors, and a customizable ServiceRequest error object you can use when the preconfigured error objects do not meet your needs.
Enforce and test access controls
Enforce existing access controls and require additional access to modify data. In addition to requiring authentication to access the API, require authorization to access data. Use the GlideRecordSecure API in your scripted REST API scripts. This API ensures that access controls defined on the underlying data are applied for the requesting user.
Require additional access controls for operations that modify data. Requests such as PUT, POST, and DELETE should require a higher level of access than GET. Configure these API resources to require a more strict ACL.
Test your access controls, both authentication and authorization, before releasing the API.
Build tests to verify functionality
Build tests that verify your scripted REST web services functionality as part of your development process. Use repeatable tests to ensure that your API functions the way you expect it to. Testing also helps ensure that changes you make do not affect the expected API behavior after you release a version. You can use a REST client application that supports automated testing, such as Postman, to facilitate testing.
Tests should validate the response code, headers, and body content as appropriate for each resource you implement. You can also use tests to validate authentication requirements, and to confirm that errors return useful responses.