This section describes the key interfaces for implementing a service interceptor in ArcGIS Enterprise. These interfaces define the core lifecycle, request and response handling, metadata access, utility methods, and logging capabilities essential for building robust interceptor logic.
IServerServicesInterceptor
This is the core interface that every service interceptor must implement. It defines the interceptor’s lifecycle and the primary entry points for initialization and runtime processing.
-
init(—Invoked once when the interceptor is registered with ArcGIS Server. Typically used to load configuration properties, initialize helper resources, set up logging, and prepare reusable state.I Interceptor Config, I Server Services Interceptor Helper, I Server Interceptor Logger) -
intercept(—Called for each incoming REST request that matches the defined url patterns. Enables inspection, modification, and logging of both the request and response objects.I Interceptor Request, I Interceptor Response, I Server Services Interceptor Chain)
IServerServicesInterceptorChain
This interface provides configuration metadata for the interceptor instance. It includes methods to retrieve the interceptor name, display name, description, class name, execution chain order, URL patterns to which the interceptor applies, and runtime properties ( for configurable behavior.
IServerServicesInterceptorHelper
This interface is effective for writing logic that varies by service type, user role, or operation, and contains the following:
- Utility methods that provide contextual and diagnostic information about the intercepted service.
- Methods to extract service metadata like service name, service type, and operation name.
- Methods to retrieve user identity information, such as username and user role.
- Data utility methods for retrieving compressed and decompressed response data.
- Type checks to verify whether the request is REST-based and the output stream is compressed.
IServerInterceptorLogger
This interface is used to log messages from within an interceptor to ArcGIS Server’s log system. It contains methods to log messages for various log levels like info, debug, warning, and severe. It also contains overload log(logLevel, message) and log(logLevel, exception) methods.
These logs are written to the ArcGIS Server logs and help with debugging, troubleshooting, monitoring, tracking runtime events, and other tasks.
Refer to IServerInterceptorLogger for more details.
IInterceptorRequest
This interface encapsulates the original HTTP servlet request, exposing only the relevant methods and properties. It supports accessing request parameters, reading headers, retrieving request metadata, handling multipart content, and reading the body stream. This interface enables fine-grained inspection and validation of the incoming request, as well as retrieval of the request attributes and the request body.
Refer to IInterceptorRequest for more details.
IInterceptorResponse
This interface encapsulates the original HTTP servlet response, exposing only the relevant methods and properties. It supports reading and modifying response headers, writing to an output stream, controlling response behavior, and managing encodings. This interface allows for the application of post-processing logic, including fine-grained inspection, transformation, sanitization, and enrichment of response data before the content is sent to the client.
Refer to IInterceptorResponse for more details.
IInterceptorRequestWrapper and IInterceptorResponseWrapper
These are wrapper interfaces used for extending IInterceptorRequest and IInterceptorResponse, respectively. It provides pass-through access with the get or get methods, which return the original object. It also replicates all getter methods from core interfaces, allowing wrappers to act as stand-ins. It enables the reuse of input and output streams, which are read only once by default.
These interfaces are particularly useful in scenarios where you need to read the request body multiple times (when chaining interceptors) since the input stream retrieved by interceptor can only be read once by default. By wrapping the original request, you can buffer and reuse the input stream. Similarly, they are also useful if you need to read the response body multiple times (when chaining interceptors) since the output stream retrieved by interceptor can only be read once by default. By wrapping the original response, you can reuse the output stream. This is also needed when you want to override the default behavior of the request and response methods.
Note: It is required that you implement these interfaces in your code if you are planning to chain multiple interceptors together or reuse the same input and output stream numerous times in an interceptor code.