Respond to comment

ploeh · Sep 23, 2021 · 3c1e51a · 3c1e51a
1 parent f60a46e
commit 3c1e51a
Showing 1 changed file with 39 additions and 0 deletions.
diff --git a/_posts/2021-09-20-keep-ids-internal-with-rest.html b/_posts/2021-09-20-keep-ids-internal-with-rest.html
@@ -308,4 +308,43 @@ <h2 id="comments-header">Comments</h2>
 		</div>
 		<div class="comment-date">2021-09-21 20:56 UTC</div>
 	</div>
+
+	<div class="comment" id="e1a154854b014ab8ad218b076579db4c">
+		<div class="comment-author"><a href="{{ HOME_PATH }}">Mark Seemann</a></div>
+		<div class="comment-content">
+			<p>
+				Christer, thank you for writing. It's possible that I'm going about this the wrong way. I only report on what's been working for me, but that said, while I <em>do</em> have decades of general programming experience, I don't have decades of REST experience. I designed my first REST API in 2012.
+			</p>
+			<p>
+				Additionally, just because one style of API design works well, that doesn't rule out that other types of design also work.
+			</p>
+			<p>
+				Finally, this particular article is an experiment. I've never done something like this in the wild, so it's possible that it does have unforeseen issues.
+			</p>
+			<p>
+				A couple of answers to your various points, though:
+			</p>
+			<p>
+				I don't foresee having to change signing keys, but if that happens, it'd be a breaking change to remove support for old keys. One might have to, instead, retire old signing keys in the same way one can <a href="/2020/06/01/retiring-old-service-versions">retire old service versions</a>. Even if a key gets 'compromised', it's not an immediate issue. It only means that any client that possesses the leaked key <em>can</em> construct URLs directly by <a href="/2013/05/01/rest-lesson-learned-avoid-hackable-urls">retro-engineering implied URL templates</a>. This would still be undocumented and unsupported use of the API, which means that ultimately, it'd be against the client developers' own self-interest in doing that.
+			</p>
+			<p>
+				<a href="/2020/10/26/fit-urls">Signing the URLs isn't a security measure</a>; it's more like a <a href="https://en.wikipedia.org/wiki/Nudge_theory">nudge</a>.
+			</p>
+			<blockquote>
+				<p>
+					"our APIs (and many others, I assume) are created not just for 3rd party integration but also for one or more 1st party front-ends, which naturally tends to receive some preferential treatment"
+				</p>
+			</blockquote>
+			<p>
+				I've written APIs like that as well, and if there's one thing I've learned from doing that is that if I'm ever again put in charge of such an API, I'll strongly resist giving preferential treatment to any clients. If a particular client needs a particular feature, the client team can develop and maintain a Backend for Frontend, which bases its own implementation on the general-purpose API.
+			</p>
+			<p>
+				My experience with supporting particular clients is that client needs evolve much faster than APIs. This makes sense. Someone wants to do <a href="https://en.wikipedia.org/wiki/A/B_testing">A/B testing</a> on the client's user interface. Depending on the outcome of such a test, at least one of the supporting features will now be obsolete. I'm not much inclined having to support such features in an API where backwards compatibility is critical.
+			</p>
+			<p>
+				But again, these things are never clear-cut. Much depends on the overall goals of the organisation - and these may also change over time. I'm not claiming that my way is <em>best</em> - only that it's possible.
+			</p>
+		</div>
+		<div class="comment-date">2021-09-23 8:07 UTC</div>
+	</div>
 </div>