<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Strangler-Fig on .NET wat we zoeken</title><link>https://blog.netwatwezoeken.nl/tags/strangler-fig/</link><description>Recent content in Strangler-Fig on .NET wat we zoeken</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 20 Nov 2025 11:26:00 +0100</lastBuildDate><atom:link href="https://blog.netwatwezoeken.nl/tags/strangler-fig/index.xml" rel="self" type="application/rss+xml"/><item><title>Strangling SOAP: migrate to modern .NET without breaking clients</title><link>https://blog.netwatwezoeken.nl/posts/strangling-soap/</link><pubDate>Thu, 20 Nov 2025 11:26:00 +0100</pubDate><guid>https://blog.netwatwezoeken.nl/posts/strangling-soap/</guid><description>&lt;p&gt;The Strangler Fig pattern is one of those transitional architecture patterns to get to a better system. But strangling SOAP is a bit difficult. If you just put a proxy in front of a SOAP service, you’ll quickly bump into a painful detail: SOAP typically exposes a single HTTP endpoint. All operations share one path, and the actual method is picked using headers like &lt;code&gt;SOAPAction&lt;/code&gt; or &lt;code&gt;action&lt;/code&gt; and the body contents. That makes the usual reverse‑proxy trick an &amp;ldquo;all or nothing&amp;rdquo; mechanism. Not at all a Strangler Fig approach. But there is a way!&lt;/p&gt;</description></item></channel></rss>