dyoder

Thank you!

That's a really great suggestion and I feel a bit silly for not having thought of it. (FWIW, there is a test form on the RapidAPI site, but it's more complicated to try and not as fun.) We'll add that. Thank you!

Hi, one of the authors here. We originally built this link preview API for our own apps. (A link preview shows a summary of the page referenced by a URL. Given a link, our API will return the corresponding title, author, publisher, and so on.) Since it worked well for us, we figured why not make it available to everyone?

The reason we decided to build our own (there are several out there) is that we wanted to pull all the data a publisher wanted to share, including all the media, and we wanted it to be fast. Specially, we wanted to edge cache that data as aggressively as possible given the source.

Hopefully, others find this useful. Let us know if there are features you'd like to see. We also launched this on RapidAPI, so let us know if you've had good or bad experience using that platform. This is our first API launch, so we're still figuring out the best way to do this. Thank you!

:)

We're not religious about REST. For example, see:

https://www.pandastrike.com/posts/20151215-http-rest-great-b...

and

https://www.pandastrike.com/posts/20160210-rest-is-the-wrong...

We've also tried to be specific in how you might approach addressing the limitations of HTTP in a way more consistent with the design of the protocol:

https://www.pandastrike.com/posts/20151022-rest-data-api

and

https://www.pandastrike.com/posts/20160509-http-is-the-new-l...

In fact, our thesis in this article is not about REST at all, but the design goals of projects like Falcor, which may be unrealistic. And it's those unrealistic expectations of what's possible are why people are turning from HTTP.

One of the authors here: we've had some internal debate on this since that article was written, summarized here:

https://www.pandastrike.com/posts/20160331-facebook-react-pa...

Technically speaking, with respect to the whole argument that React is “just a library,” part of the problem is that it isn't perceived that way by many developers. The first auto-complete option (for me anyway) when I type “Web Components vs…” is React.

That said, the developer experience around Web Components is meh. Part of our frustration is that it would have been cool to see Facebook invest all the effort into Web Components-based technologies instead of going off on their own.

Have you read Drucker?

Right. And then when those features aren't available in the browser, that's used as a justification going back to proprietary (aka native) platforms. It's a circular argument made by people determined to return to the days before we had an Open Web, for whatever reasons. If you don't want to use the features, nobody is forcing you to do so.