Opened 11 years ago
Closed 10 years ago
#23419 closed enhancement (wontfix)
Use version 1.1 for Twitter.com oEmbed
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.4 |
Component: | Embeds | Keywords: | dev-feedback has-patch |
Focuses: | Cc: |
Description
Version 1 of the API is deprecated and it will be retired soon. We should work on moving to version 1.1.
This sounds like a no-brainer, however one of the biggest changes between the two versions is the authentication model. Version 1.1 does not support unauthenticated requests. This means that we can no longer anonymously query the oembed endpoint.
I'm not sure we want to build an OAuth client into Core specifically for this and have users go through an authentication process before being able to embed tweets. Another option is to construct the embedded tweets manually without querying Twitter's API.
This should also fix most of the "tweets won't embed" problems people are having on shared hosts, since unauthenticated requests in v1 are rate limited by IP.
Attachments (1)
Change History (13)
#3
@
11 years ago
I think we should talk with someone at Twitter before jumping into this. Because requiring authentication for an oEmbed endpoint is fairly insane and renders it useless.
Their own documentation on Embedded Tweets makes specific reference to us: https://dev.twitter.com/docs/embedded-tweets.
Embedding from WordPress and other CMSs
Some content management systems like WordPress have created an optimized workflow for embedding Tweets. In WordPress you can simply copy the URL for a Tweet and paste it on a single line in your post. WordPress will do the rest of the work to insert the proper embed code and make the Tweet appear in your content. For example:
https://twitter.com/BarackObama/statuses/266031293945503744
To add this behavior to your CMS, read the section below on Embedded Tweets for Developers.
Additionally, this page (updated yesterday) still prominently references the 1.0 oEmbed endpoint. So perhaps they have plans to keep old-school oEmbed support alive.
#5
@
11 years ago
I left a comment on Twitter's discussion thread for the v1 API retirement (here) asking about the status of the v1 API for embedded Tweets and whether v1.1 will allow unauthenticated embeds. It's awaiting approval. I'll update if I get a reply.
#8
follow-up:
↓ 9
@
11 years ago
Initial response from Twitter is that "the endpoint will continue to operate unauthenticated, as-is the spirit of oEmbed." Still trying to confirm whether that means 1.0's oEmbed endpoint will remain in operation past the 1.0 shutdown, if 1.1's oEmbed endpoint will be changed to be entirely unauthenticated, or both. Either way, we're in the clear in terms of not needing to implement something new.
#9
in reply to:
↑ 8
@
11 years ago
Replying to nacin: Great news! Any word about whether the March "blackout tests" will affect the v1 oEmbed endpoint?
#11
@
10 years ago
It looks like the oEmbed endpoint will continue to work on v1 of the API:
Developers may have observed that unauthenticated requests to /1/statuses/oembed still functioned during the blackout test. Twitter's support for OEmbed transcends our API versioning scheme and we'll continue providing this method of Tweet syndication. Over time the URL for our OEmbed service may change; we recommend that developers tolerate HTTP redirects on this method to better future-proof your integrations.
23419.diff drops the oEmbed and uses a regular embed with a callback, similar to what we have for Google Video. Downside is that the tweet content is not available without the embedded script, for example in feed readers.