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!
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.
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.
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.
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.
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).
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.
- 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
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.
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.