draft-toomim-httpbis-versions HTTP mapping (and WebDAV Versioning)

On 30.10.2024 03:50, Michael Toomim wrote:
 > ...
> I suppose it depends on how much detail we go into. Here's an overview.
>
> 1. WebDAV only supports centralized versioning.
>
>     WebDAV's basic model of LOCK/UNLOCK, and CHECKIN/CHECKOUT/UNCHECKOUT
>     assumes a central server controlling a lock, that clients must check
>     stuff out from, and check in to.
>
>     This makes it incompatible with distributed versioning systems, such
>     as git, CRDT, and OT, which limits the applicability of the WebDAV spec.
>
>     It also adds unnecessary complexity. Distributed versioning does not
>     need these methods, and does not need other methods like MKCOL. This
>     unnecessary complexity has limited adoption of WebDAV.

Yes, WebDAV Version Control uses a centralized model. If you want a
distributed system, it's not for you. Note that this is an issue WebDAV
Versioning, not WebDAV in general.

> 2. WebDAV takes up URL space by requiring each version of a resource to
> have a URL.

I'd argue that this is a feature. If versions are different resources,
they should have their own URIs. I don't think that content negotiation
is the right approach; in particular as it does not work when different
versions sit on different servers.

>     This was how we differentiate WebDAV in the spec:
>
>         1.1.3.  Versioning encoded within URLs
>
>             In practice, application programmers tend to encode versions
>         within
>             URLs:
>
>         https://unpkg.com/braid-text@0.0.18/index.js

Why is that a problem? (and no, they don't have to)

>             This approach is common in API versioning (e.g.,
>         /api/v1/resource).

API versioning is an entirely orthogonal issue, no?

>             However, it has several drawbacks:
>
>             1. It loses the semantics of a "resource changing over time."
>                Instead, it creates multiple version resources for every
>         single
>                logical resource.

You don't lose that concept if the versiones resource continues to have
the same URI - thus it keeps its identity. It's only the previous
versions that get a new URI. And those are static, thus do not need the
concept of "changing over time".

>             2. It necessitates additional standards for version history
>         on top of
>                URLs (e.g., Memento, WebDAV, Link Relations for Versioning
>                [RFC5829]).

How is that different from adding new response fields?

>             3. Given a URL, we still need a standard way to extract the
>         version
>                itself, get the previous and next version(s), and
>         understand the
>                format of the version(s) (e.g., major.minor.patch).

For *finding* the predecessors and successors, you can use an existing
link relation, see <https://www.rfc-editor.org/rfc/rfc5829>.

>             4. This approach can lead to URI proliferation, potentially
>         impacting
>                caching strategies and SEO.

In this case, you get more URIs, but less complicated cache keys (see
the requirement to use "Vary"). And do you believe search engines will
start looking at the new header fields? Do you *want* search engines not
to find previous versions?

>             5. It may complicate content negotiation and RESTful design
>                principles.

I'd argue the opposite is true. But let's hear from Roy :-).

>             The choice to embed versions into URLs can be useful, but
>         carries
>             with it additional tradeoffs.  A versioning system does not
>         need to
>             depend on allocating a URL for each version; but could be
>         compatible
>             with doing so.

It doesn't need to, but I believe it should (see arguments above).

> 3. WebDAV has unnecessary complexity for simple tasks.

Yes. We don't need to discuss complexity here, what concerns me more how
the data model is mapped to the Web in general.

That said:

>     Let's say you GET a resource /foo with WebDAV, and now you want to
>     know what version it is. This requires two more requests: a PROPFIND
>     to get the version-history URL, and then another PROPFIND on that
>     URL to get the list of URLs. Then you have to parse the XML, and

Actually, there's a REPORT that could be used to avoid at least one
round trip: <https://datatracker.ietf.org/doc/html/rfc3253#section-3.8.1>.

>     figure out which of those URLs is the most recent, and then assume
>     that it's the same one as the resource you just did the GET for. If

No, you would look at the the checked-in or checked-out properties (see
<https://datatracker.ietf.org/doc/html/rfc3253#section-3.2.1>).

>     you're not sure, you might have to request that URL explicitly, and
>     compare its value to the one you got.

Nope.

>     That's 3 or 4 requests, total. And 2 of them involve digging through
>     XML with a new PROPFIND method.

It's not that new -). And of course if would be an option to use JSON
instead (as you're defining something new anyway), you just would need
to define the mapping.

>     With this Versioning spec, you get the current version in the
>     original GET request automatically. It's in the Version: header.
>
>     See the example requests and responses here:
>     https://news.ycombinator.com/item?id=40481003
>
> Do you think I'm missing anything important here?

I believe you slightly overstated the complexity of WebDAV here.

But yes, I understand that WebDAV Versioning is not suitable for your
use case; let's focus on the general mapping to HTTP resources.

Best regards, Julian

Received on Wednesday, 30 October 2024 10:20:10 UTC