Spike uses HTTP headers to pass information through the network. Your application must pass along these headers with every service request, to enable the full Spike functionality. Spike uses headers in order to:
  • Group together multiple requests into a single logical transaction. For example, your frontend may call a backend service which itself calls 3 more backend services. All four backend calls should be seen as part of the same end-to-end request flow.
  • Pass along commands to upstream Spike proxies. For example, you tell your local Spike process to simulate a 404 for a specific service, but that service actually resides on an upstream node, and not on your local machine. The Spike headers that get passed along upstream will eventually be read by the other service, and trigger the correct behavior.
  • Pass along data from upstream services, to downstream Spike proxies. For example, if you have a service call that itself branches off into 3 more service calls upstream (and they all run through Spike), then statistics about the upstream services will be passed back to the original Spike nodes, via response headers.
In the above cases, we show how Spike requires your application to pass along Spike-specific request headers and also a response header.

Spike Request Headers

  • SPIKE-TRACE - Your application can set this to any string value to tag the service request and, all subsequent service requests that branch off of the original.
    The value should contain all or at least some randomly-generated content. Otherwise, independent requests will be incorrectly grouped together.
    Note that you only need to set the trace ID at the root of your service call graph. For example, set it when making requests from your externally-facing frontend server, to backend services. The trace ID will be encoded inside the SPIKE-REQUEST header, which is passed along to all upstream services (see below).
  • SPIKE-ORIGIN - Your application can set this to any string value to set a name for this node. It is used by Spike to identify where a call originated from. This name is displayed in the Graph and Timeline views of the Spike web UI. It is not necessary to set this header from a service that is called through/from Spike, but rather only from applications or services that are the initial link in a chain of service calls. E.g., you might set SPIKE-ORIGIN header with the value "frontend" in all outgoing requests from your frontend server, and with the value "api" in all backend requests from your API server. Then Spike can differentiate the origin of the service calls.
  • SPIKE-REQUEST - This HTTP header is set by Spike, and should be read by your application and copied to every outgoing service request. It will encode commands to be performed by upstream services, and also will carry along the request ID that you originally specified with SPIKE-TRACE.

Spike Response Header

  • SPIKE-RESPONSE - Your application should read this HTTP response header, in the response to any service call that traveled through Spike. Then, this response header should be passed along to the downstream service. For example, if A calls B which calls C, then B should get the SPIKE-RESPONSE header and set it as it's own response header back to A. That way, A will get information from C.