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.

Quantum computing is not on the list. I wrote a novel, Qubit, in which quantum computing plays a central role.

http://www.amazon.com/Qubit-Finn-Mack-ebook/dp/B00F45N40O

Not on the list, and I'm not a physicist so from that standpoint, I may not have gotten everything right. Still, I'd like to think Qubit would pass muster.

Short version: Convince great software developers to work mostly for stock options ($150K for 3 employees) and “harass [them] into programming day and night,“ while selling promises that they will need to back up with working software.

Not an original strategy.

Is it so much of a stretch to believe that a vendor might believe it is in their best interest to control the application platform? Why give Apple the benefit of the doubt here? Ironically, one reason to do that is that Apple is active in defining and implementing Open Web standards, many of which are aimed at improving the Web as an app platform. Which, in turn, is exactly why this is still an “interesting narrative”--both Web and native are rapidly evolving.

Many, if not most, apps that depend on the Internet in some fashion do not handle losing the connection gracefully. Furthermore, it has been possible to write Web apps that can run disconnected (assuming they've been run at least once with a working connection, analogous to downloading an app).

Did OpenBSD just standardize on an HTTP server they wrote in 2 weeks, has no tests, doesn't fully implement the spec…and then brag about it?

Many of these responses hilariously demonstrate why enterprise software interaction design is so poor: the market simply doesn't care.

The root cause is not that enterprise software vendors have no taste, it's that the stakeholders involved in the procurement process don't value interaction design. Like any market, it's likely that the vendors that are successful value those things that their customers value, and interaction design is not one of those things.

The vendors that are passionate about design eventually do something else, because their work isn't valued by the enterprise market. The vendors that remain in the market either don't value design or aren't committed to it. And, by extension, the best designers don't stick around in companies where their talents aren't valued.

you're absolutely right. and i'd be fine with that if the objection was just that: this is too hard to implement, or we don't have time, and so on. it's the rationalizing that's annoying. and obviously DropBox has the resources to implement whatever design they choose.

My two cents:

- if your queries get that complex, introducing a subordinate query resource is a pretty reasonable measure; in a world where people commonly use URL shorteners, why is this controversial?

- "don't break the web" isn't just about bookmarks; it's also about interoperability, in general

- for example, supporting GET means responses are now cacheable, which may be useful in many situations

- the author is mostly just pointing out that DropBox hasn't followed the REST style, and he's correct; there are reasonable design alternatives that do

- therefore, if REST is good, than this design is bad; given the success of the Web and HTTP, whose fundamental design follows the REST style, it always mystifies me how many people find this objectionable

God forbid you let people work from home.

A URL is an identifier for a resource. Everyone now has the same URL (identifier) for their shopping cart. If you're goal is to use HTTP effectively, this is bad. For example, it breaks HTTP caching. In effect, you have a variant of the RPC pattern that you say you're trying to avoid.

> ...it's just an API failure

This. As far as the bandwidth issue goes, effective use of caching and compression can go a long way. Schemes varying the responses via the URL compromise schema validation based on media type (see JSON Schema, for example). Specific cases where fat or thin requests truly make a difference can be addressed with additional media types.

Very interesting. I was thinking something similar could be done in Haskell.

The negative response to this post is over the top.

At most, you can say that they overstated their case by neglecting to talk about server trust and using the word "comfortable" in an article about security. :)

To address a few red herrings:

Saying that no solution is better than a flawed solution is absurd. There's no such thing as impenetrable security. On that basis, we shouldn't bother with HTTPS. For that matter, we shouldn't bother with passwords, either.

We do these things because they make attacks incrementally more difficult and thus redirect attackers' efforts to more vulnerable targets, or make it expensive enough not to bother. Every little bit helps.

Saying that you can't do this because you have to verify everything on every page load utterly ignores the past decade of development of rich client applications.

Saying that you shouldn't do this because it's been tried before also ignores virtually the entire history of technological innovation.

This is important problem and constructive criticism from security experts is extremely valuable. But the only "sophistry" I'm seeing here is from the people who can help the most.

This is a beta, invite-only app bootstrapped out of the proverbial garage. Their blog post on the technical details missed a few things. If you've ever been in those shoes, you know how easy that is to do. I've seen billion dollar companies do worse. Most of the article was accurate, well-written, and probably helpful to a lot of readers.

Help 'em out, don't tear 'em down.

make sure your login and signup are via HTTPS before you go much further.

You get 'windowed queries into the channel history for free' on spire.io as well.

FWIW, we use HTTP as intended, not to tunnel RPCs.

Correct. We do not yet work well offline. Request buffering, data storage, and synchronization are on our roadmap.

Also, you can implement data synchronization over a messaging layer but not the other way around. So I'd say our approach is actually more flexible. And we do plan to introduce APIs to make data synchronization easier.

Wasn't aware of it, actually. Thanks for mentioning it. Looks very interesting. I'll also amend the blog post.

Nailed it. Composite resources and good use of caching with fine-grained resources can go a long way.

HTTP is a pretty sophisticated protocol, when all is said and done. That means there is a learning curve in using it effectively. However, a good BaaS takes care of that for you, including providing default client libraries that know how to take advantage of the API properly.

(Full-disclosure: my company, spire.io, has recently launched a REST API BaaS that attempts to address exactly these concerns.)

We use CORS at spire.io.

Thanks for your suggestion, Matthew.

We do anticipate some applications wanting more than one instance. There are two scenarios where this comes up.

1. You want separate connections per instance. This is useful in load testing, among other things.

2. You want to provide different default options for different instances.

Neither of these scenarios is supported very well in this release, but we expect to add support for them shortly.