En oEmbed Spezifikation werden 2 verschiedene Möglichkeiten genannt, den oEmbed-Inhalt einer URL zu finden:
- Kenntnis des API-Endpunkts der Website und Übergabe der gewünschten URL über einen GET-Parameter, wenn sie mit dem angegebenen URL-Muster übereinstimmt.
- Ermitteln der URL der oEmbed-Version dank einer
<link rel="alternate" type="application/json+oembed" ... />
(odertext/xml+oembed
) HTML-Kopfzeile.
Der 2. Weg scheint allgemeiner zu sein, da man nicht eine ganze Liste von Anbietern speichern und pflegen muss. Außerdem sind Listen von Anbietern ein Zeichen für ein zentralisiertes Internet, in dem es nur wenige Akteure gibt. Dieser Ansatz ist kaum skalierbar.
Ich kann mir jedoch vorstellen, dass der 1. Ansatz für Websites, die von anderen zur Verfügung gestellte Ressourcen analysieren können, von Nutzen ist. Ich kann zum Beispiel eine oEmbed-Version von Videoseiten der Website Foo anbieten. Aus verschiedenen Gründen, vor allem aus Sicherheitsgründen, würde ich jedoch niemandem trauen, der sagt: "Ich kann Ressource X für Sie analysieren", es sei denn, der Autor von X ist damit einverstanden, was uns wieder zu Ansatz 2 bringt.
Meine Frage ist also: Was habe ich hier verpasst? Welchen Nutzen hat die 1. Methode im Umgang mit oEmbed? Warum sollte man zum Beispiel eine ganze Liste von Endpunkten und Mustern speichern (und aktuell halten)? wie oohEmbed es tut wenn Sie eine generische Möglichkeit haben, sie im Handumdrehen und für praktisch jede Quelle im Internet zu finden?
Eine damit eng zusammenhängende Frage, die meines Erachtens gleichzeitig gestellt werden könnte (bitte korrigieren Sie mich, wenn ich falsch liege): Was passiert, wenn man keinen zentralen Endpunkt für oEmbed-Inhalte bereitstellt, sondern, sagen wir, einen Parameter '?version=oembed' auf jeder URL erwartet, der die oEmbed-Version anstelle der Standardversion zurückgibt?