Scripted REST APIs good practices
Summarize
Summary of Scripted REST APIs good practices
This guidance helps ServiceNow customers design and implement scripted REST APIs that are consistent, reliable, and secure. It emphasizes following REST API conventions, versioning, informative responses, error handling, access control enforcement, and testing to ensure robust API behavior.
Show less
REST API Conventions
- GET requests should only retrieve data and never modify it.
- POST requests create new records without modifying existing ones.
- PUT and PATCH requests modify existing records.
- DELETE requests remove records.
Versioning
Use versioning to manage changes and introduce new functionality without breaking existing integrations. Create new API versions for significant changes and encourage clients to specify the version explicitly. Optional new features can be added via parameters in existing versions.
HTTP Status Codes and Error Information
- Return appropriate status codes to clearly indicate request outcomes, such as:
- 200 for successful requests
- 201 when a record is created
- 204 when a record is deleted
- 40X codes for client errors (e.g., 400, 401, 404)
- 50X codes for server errors (e.g., 500, 503)
- Provide meaningful and descriptive error messages to help clients understand issues without needing to consult documentation.
- Leverage preconfigured error objects or customize error responses using ServiceRequest error objects.
Access Control Enforcement
Secure your APIs by enforcing both authentication and authorization. Use the GlideRecordSecure API to respect data access controls for the requesting user. Require stricter access controls for data-modifying requests (PUT, POST, DELETE) compared to read-only requests (GET). Test all access controls thoroughly before release.
Testing Best Practices
Develop repeatable tests to validate API functionality, ensuring consistent behavior and preventing regressions. Tests should verify response codes, headers, body content, authentication, authorization, and error responses. Use automated REST client tools like Postman to streamline and automate testing.
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.