[Engine-devel] REST-API: Exposing correlation-ID

[Eoghan Glynn]

> >> >> 1) what's the name you'd give this parameter? job-id? batch-id?
> >> >> flow-id? command-id? correlation-id???
> >> 
> >> job-id will confuse us with engine's job-id which is a single
> >> command
> >> today.
> >> correleation-id is pretty long and confusing as implies on
> >> correlation
> >> of something.
> >> 
> >> I'm for flow-id or batch-id.
> >> batch-id sounds the right one to me, as this is identifying a
> >> batch
> >> of
> >> calls.
> 
> >How about log-id?
> >It isn't supposed to be unique, or of any format, it's just used to
> >log calls, so log-id is the most natural (or log-tag or whatever
> >name you prefer).
> >
> >Also I think it's more of a header-type parameter since it's
> >metadata for the call, not an actual parameter that influences the
> >outcome of the "flow".
> 
> I actually believe you're right, it probably is better to pass this parameter as
> an http header. You've changed my mind about this (objections, anyone, to passing
> it as a header as opposed to passing it as a url parameter)?

Agree also that a header is much more natural in this case than a URL parameter.

Also in the case where the client does not specify the ID themselves on the
initial request, a generated value should be returned as response header
(so that this can be passed as request header with the next request if part
of the same over-arching task, or else just to aid log interpretation if the
initial request was standalone but still mapped internally to multiple backend
actions).


> About log_id - it could sound like there are numerous logs, and the user is asked
> to specify the ID of the log he wishes to write to. But perhaps: log_entry_id?

Is there any possibility that this identifier may be leveraged for uses other than
log interpretation?

One other suggestion to add into the mix: MetaTask-ID.

Cheers,
Eoghan