Add comment metadata

_posts/2021-09-20-keep-ids-internal-with-rest.html

@@ -298,14 +298,14 @@ <h2 id="comments-header">Comments</h2>
 		<div class="comment-date">2021-09-21 16:27 UTC</div>
 	</div>
 
-	<div class="comment" id="TODO">
+	<div class="comment" id="6a7b06cf97e9453bafe5ddafa5156093">
 		<div class="comment-author"><a href="https://www.relativisticramblings.com/">Christer van der Meeren</a></div>
 		<div class="comment-content">
 			<p>Your URLs include a signature, which changes if you need to switch signing keys. Furthermore, the base URL for your API may change. The entities are still the same; the restaurant previously at old.domain/restaurants/1?sig=abc is the same as the restaurant now at new.domain/restaurants/1?sig=123. With your proposed bookmark-based solution, the API clients would effectively lose the associations in their system.</p>
 			<p>Also, indexing a very long varchar column probably works fine for tables that are fairly small and not overly busy. But for large and/or busy tables containing entities that are created every second of every day (say, passages through gates at hundreds of large construction sites, which is one of the domains I work with), I think that the performance would suffer unreasonably. (Admittedly, I have of course not measured this; this is just speculation, and anyway not my main point.)</p>
 			<p>You say you write APIs with arbitrary clients in mind. I do, too. That is one of the reasons I design my APIs at REST level 2 instead of 3. (JSON:API does offer some possibility of just "following links" if the client wishes to do that, though it is does not allow for APIs that are fully level 3/HATEOAS.) Having stable IDs with well-known formats and being able to construct URLs seems pragmatically like a good solution that keeps client developers happy. I do not have decades of experience, but I have never encountered clients who have been unhappy with my decision to go for level 2 instead of level 3. (I imagine I would have encountered some resistance in the opposite case, though that is pure speculation on my part.) Furthermore, I have never encountered the need for breaking changes that would be non-breaking by level 3 standards.</p>
 			<p>You say it makes little sense to take "special needs" into account. Idealistically, I agree. Pragmatically, 1) SQL databases are so ubiquitous and have been for such a long time that making life better for those developers by including an ID with a guaranteed format seems like a fair decision, and 2) 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 (e.g. features and designs that probably aren't useful to other clients).</p>
 		</div>
-		<div class="comment-date">TODO</div>
+		<div class="comment-date">2021-09-21 20:56 UTC</div>
 	</div>
 </div>