Anything that further pushes and supports oEmbed is a great thing. It would be nice to see a list of what providers you support -- I don't want to callback every URL in a blog post or other thing to you, and you probably don't want me doing that either.
Great idea -- I will add a list of providers. I will say I support close to 200. If you are interested in that list in the short term, get in touch with me and I'll send you that list :) Contact info is on the page :)
I believe embedly exposes a list of regular expressions for matching URLs -- if you would share your regexes that be very helpful to library developers.
I don't want to sound like I'm being negative because this is really cool. When you promise that it will always be free, my immediate thought is that it's unsustainable. You're putting yourself into the position of one day breaking your promise or shutting down the service if you don't find some other business model to build on. Why not leave the door open for charging later on?
oEmbed is a standard, therefore you're not locking anyone into your platform by making it free now and charging later. If they don't like the price, they can just switch back to Emed.ly or some other provider.
I completely understand where you are coming from -- Just had this conversation with someone over twitter.
oEmbed is a standard, and I really think there are a lot of cool things that can be done with it given the opportunity. Currently, the API is not rate limited, but this may be something I will have to look into in the future (I have only load tested up to 250req/sec). I will be adding a TOS in the few weeks.
Where I do plan on charging, is expanding the api to include a "kitchen sink" where I include all data that I can possible grab from a URL. I think this will add real value to the API, and I will end up charging for it once it is finished (probably a few months down the road).
oEmbed.io will always be free. If you want to pay or don't like my conditions, then you can go use embed.ly. But I genuinely feel like this is a contribution I am willing to make to the community.
Hopefully that sheds a little more light on where my head is at with this!
In our service we're oembedding external content but we're a bit frustrated as often things stop working and maintaining the js library is an extra effort.
I spoke with the author of [1], but he was not really into using 3rd party services...
I think also a server-side library would be useful. You might think to use a service like Mashape to avoid the problem of choosing a language.
Edit: oh, and mobile. We're having a lot of troubles replicating the same embed experience on iOS (and I have no experience on android/windows phone, so I assume the worse ;)
I like the concepts behind iframely better than those behind oEmbed, because you get an iframe URL, which is safer to embed than 3rd party HTML and you can change the size of the iframe on your own (no need for another request to get the embed code of another size). Their endpoint isn't free, but their software is. So you can run your own iframely server, if you want.
https://github.com/itteco/iframelyhttp://iframely.com/http://iframely.com/debug
I submitted a few patches concerning HTML parsing, Google Maps, OpenStreetMap, Magnatune.com, OCReMix.org, Firefox Marketplace, Tindeck.com (and a few tiny bugfixes).
Thanks for the mention (and contributing) Mathias.
A quick clarification:
#1: our endpoint is "community" one. It's free and open for dev purposes, but it's not suggested for production use as one can easily self-host it (though we use same server for number of heavy traffic apps like Iframely for Gmail chrome ext).
#2: Iframely now has the oEmbed endpoint too. We trim much richer infos into oembed format for backwards compatibility.
Ill be at the startupschool sat., if you need any graphic/ui design work for this project, let me know, ill help you out. Rmena123 @ gma i l . Hope to see you around.
18 comments
[ 3.3 ms ] story [ 67.9 ms ] threadThanks!
Again, if you need it short term -- don't hesitate to reach out!
I will make a better inspector so you can interactively see what is being sent, and what you are getting back :)
oEmbed is a standard, therefore you're not locking anyone into your platform by making it free now and charging later. If they don't like the price, they can just switch back to Emed.ly or some other provider.
oEmbed is a standard, and I really think there are a lot of cool things that can be done with it given the opportunity. Currently, the API is not rate limited, but this may be something I will have to look into in the future (I have only load tested up to 250req/sec). I will be adding a TOS in the few weeks.
Where I do plan on charging, is expanding the api to include a "kitchen sink" where I include all data that I can possible grab from a URL. I think this will add real value to the API, and I will end up charging for it once it is finished (probably a few months down the road).
oEmbed.io will always be free. If you want to pay or don't like my conditions, then you can go use embed.ly. But I genuinely feel like this is a contribution I am willing to make to the community.
Hopefully that sheds a little more light on where my head is at with this!
In our service we're oembedding external content but we're a bit frustrated as often things stop working and maintaining the js library is an extra effort.
I spoke with the author of [1], but he was not really into using 3rd party services...
[1] https://github.com/starfishmod/jquery-oembed-all
If you let me know your email, I will be sure to reach out to you once it is finished!
If you have any other ideas, let me know! :)
I think also a server-side library would be useful. You might think to use a service like Mashape to avoid the problem of choosing a language.
Edit: oh, and mobile. We're having a lot of troubles replicating the same embed experience on iOS (and I have no experience on android/windows phone, so I assume the worse ;)
I submitted a few patches concerning HTML parsing, Google Maps, OpenStreetMap, Magnatune.com, OCReMix.org, Firefox Marketplace, Tindeck.com (and a few tiny bugfixes).
A quick clarification: #1: our endpoint is "community" one. It's free and open for dev purposes, but it's not suggested for production use as one can easily self-host it (though we use same server for number of heavy traffic apps like Iframely for Gmail chrome ext).
#2: Iframely now has the oEmbed endpoint too. We trim much richer infos into oembed format for backwards compatibility.