<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Api Design on An observer's log</title><link>https://blog.rtshkmr.com/tags/api-design/</link><description>Recent content in Api Design on An observer's log</description><generator>Hugo</generator><language>en</language><atom:link href="https://blog.rtshkmr.com/tags/api-design/index.xml" rel="self" type="application/rss+xml"/><item><title>API Gateway</title><link>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/api-gateway/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/api-gateway/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;appears in nearly every system design; the single entry point pattern&lt;/em&gt;&lt;/p&gt;</description></item><item><title>API Design</title><link>https://blog.rtshkmr.com/reference/archi/core/concepts/api-design/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/core/concepts/api-design/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;the craft of designing APIs; shows engineering judgement, not just pattern knowledge&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Backend for Frontend (BFF)</title><link>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/backend-for-frontend/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/backend-for-frontend/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;solves the &amp;ldquo;one API doesn&amp;rsquo;t fit all clients&amp;rdquo; problem&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Protocol Choices</title><link>https://blog.rtshkmr.com/reference/archi/patterns/encoding-and-formats/protocol-choices/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/encoding-and-formats/protocol-choices/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;REST vs gRPC vs GraphQL is a standard interview question&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Web-gRPC Proxy</title><link>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/web-grpc-proxy/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/web-grpc-proxy/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;decoupling internal gRPC from external REST via a stateless proxy&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Strangler Fig (API Migration)</title><link>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/strangler-fig/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/strangler-fig/</guid><description>&lt;p&gt;🟡 P2 &amp;mdash; &lt;em&gt;Martin Fowler&amp;rsquo;s pattern for incremental migration from monolith to microservices&lt;/em&gt;&lt;/p&gt;</description></item><item><title>API Versioning Strategies</title><link>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/api-versioning/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/api-versioning/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;how you evolve public APIs without breaking consumers&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Communication &amp; API Design</title><link>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/</guid><description/></item></channel></rss>