<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Service-Tokens on DRM HSE</title><link>https://www.drmhse.com/tags/service-tokens/</link><description>Recent content in Service-Tokens on DRM HSE</description><generator>Hugo</generator><language>en</language><lastBuildDate>Wed, 15 Jul 2026 18:43:42 +0300</lastBuildDate><atom:link href="https://www.drmhse.com/tags/service-tokens/index.xml" rel="self" type="application/rss+xml"/><item><title>Caching Service Tokens with a Gravitee Loopback API</title><link>https://www.drmhse.com/posts/thinking-sideways-the-loopback-pattern/</link><pubDate>Sun, 15 Mar 2026 00:00:00 +0000</pubDate><guid>https://www.drmhse.com/posts/thinking-sideways-the-loopback-pattern/</guid><description>&lt;p>The gateway would not act as the token store I had in mind.&lt;/p>
&lt;p>Each request through our business API made an HTTP callout for a service token, even though that token remained valid for hours. Caching it seemed straightforward. The Cache policy available to us, however, cached an upstream HTTP response and returned that response to the caller. It did not load an arbitrary value into a context attribute and continue the same request flow.&lt;/p></description></item></channel></rss>