title: What's the point of oEmbed API endpoints and URL schemes vs. link tags?
body: <p>The <a href="http://oembed.com" rel="nofollow">oEmbed</a> specification mentions 2 different ways of finding the oEmbed content of an URL:</p>
  
  <ol>
  <li>Knowing the API endpoint of the website and passing it, through a GET parameter, the URL you want info about, if it matches the URL pattern it declared.</li>
  <li>Discovering the URL of the oEmbed version thanks to a <code>&lt;link rel="alternate" type="application/json+oembed" ... /&gt;</code> (or <code>text/xml+oembed</code>) HTML header.</li>
  </ol>
  
  <p>The 2nd ways seems more generic, as you don't have to store and maintain a whole list of providers. Moreover, lists of providers are the sign of a centralized internet, where only a few actors exist. This approach is hardly scalable.</p>
  
  <p>I can see a use for the 1st approach, though, for websites that can parse resources made available by someone else. For example, I can provide an oEmbed version of video pages from website Foo. However, for several reasons, mainly security-related, I wouldn't trust someone who says "I can parse resource X for you" unless X's author is OK with that, which brings us back to approach 2.</p>
  
  <p>So my question is: what did I miss here? What's the use of the 1st method of dealing with oEmbed? For instance, why store (and maintain up-to-date) a whole list of endpoints and patterns <a href="http://code.google.com/p/oohembed/source/browse/app/provider/endpoints.json" rel="nofollow">like oohEmbed does</a> if you have a generic way of discovering it on-the-fly and for virtually any resource on the internet?</p>
  
  <p>As a very closely related question, which I think may be asked at the same time (please correct me if I'm wrong): what happens if one doesn't provide a central endpoint for oEmbed contents, but rather, say, expect a '?version=oembed' parameter on each URL, that returns the oEmbed version instead of the standard one?</p>