Re: What is a Version?

Hi All,

I previously replied to Michael privately and thought it might be useful to share with the group:

Having reflected on this question for some time, I wanted to share a conceptual observation. In short, treating time as a simple one-dimensional vector can be misleading, and attempts to encode it this way often introduce subtle errors that are difficult to manage.

In direct response to the question “What is a version?” I would frame it as a morphism. Including version information in the URI or request headers effectively promotes the resource from a static object to a morphism in the category of its state transitions, with each version representing a particular transformation along its evolution. Standard HTTP methods like GET and PATCH already handle this selection adequately, so explicit versioning is unnecessary.

The categorical structure of resources and their transformations is a property of how the protocol is used, rather than something the protocol itself should encode. Transforming the HTTP graph of resources into an enriched category, or a fibration over categories, is conceptually appealing, but it would represent a fundamentally different protocol. REST deliberately keeps the resource graph at a single layer; introducing categorical abstractions at the protocol level would likely increase complexity and invite errors that REST was designed to avoid.

Kind regards,

Iain

> On 13 Mar 2026, at 06:28, Nico Williams <nico@cryptonector.com> wrote:
> 
> On Fri, Mar 13, 2026 at 03:59:35PM +1100, Mark Nottingham wrote:
>> I haven't been following the discussion closely, but I will observe
>> that people tend to register very abstract protocol artefacts and hope
>> that they'll be reused broadly. Link relations are especially prone to
>> this. While that approach succeeds sometimes, it's not as common as
>> people think. 
>> 
>> What's much more successful is defining a link relation as part of a
>> specific protocol -- you shouldn't specify an exact media type because
>> this isn't media types, but behaviourally the expectations should be
>> tight. Those link relations tend to provide more value IMO.
> 
> This is good advice.
> 
>> So here instead of something wooly like "version" why not
>> "braid-commit"? People know what that refers to.
> 
> There is a chance that the link relation name might be generically
> useful, and the I-D in this thread is not specifically about Braid -I
> think- so maybe that's what is needed.  Anyways, using a specific name
> is not likely to cause too much trouble if it turns out that a generic
> name could have been used.
> 
>> Likewise with the header names -- instead of trying to solve
>> Versioning for All of HTTP, it might be more approachable and workable
>> to say "here's a specific model of versioning and how it's mapped to
>> HTTP", with an appropriate prefix, like "Braid-Version".
> 
> +1
>

Received on Friday, 13 March 2026 12:11:37 UTC