I spoke on Building APIs, focusing mostly on the upfront design of APIs, at the most recent Las Vegas PHP Meetup. Overall this was defiantly one of my better talks with lots of good feedback. One key things helped I believe in the preparation and eventual presentation of the talk. I presented a rough version of this to my fellow Loadsys employees with some valuable feedback provided from them.
It’s no longer possible to write a single app that takes advantage of the full range of Mac OS X features. Some APIs only work inside the Mac App Store. Others only work outside it. Presumably, this gap will widen as more new features are App Store–exclusive, while sandboxing places greater restrictions on what App Store apps are allowed to do.
via Michael Tsai – PDFpen and iCloud. My largest long-term fear of OSX is that Apple will slowly turn off the ability for applications to be useful without using the App Store and thus some Apps may just not exist anymore (SuperDuper is the easy example).
Today at Google I/O, we launched the developer API of Google In-App Payments for the web. In-App Payments enables any web application to receive payments from users and keep them engaged in your application. It is available to all US developers in sandbox today and will be followed by a consumer launch and an international rollout over the summer.
via The Official Google Code Blog – Making money with Google In-App Payments for the Web. The most interesting part of this is the 5% fee, most payment services charge 2-3%, so double that for Google to cover their hosting costs and such and it seems pretty reasonable. Here is where it gets interesting this puts Apple at a distinct dis-advantage. Apple charges 30% on everything (purchase an app, music, in-app purchases, etc). For ebook readers this creates a non-existent business model due to the agency model that publishers now require all books sold to recieve 70% of the purchase price (ie not wholesale price but what the customer actually paid). So 30% to Apple and 70% to the publisher means nothing get’s left over for the middle-person. That 70% cut could be argued as a problem, but the publisher is one paying for the advertising, development and writing of the book itself, 70% seems like an acceptable cut.
Google is really demonstrating what seems like the fairer margin for the service that serves, stores, builds the store, etc. Apples cut feels too high. Apple does valuable work and important work and it’s a fair argument that without all of Apple’s work there wouldn’t even be this store or platform for developers and publishers to sell their content. But the margin that Apple takes doesn’t seem right, especially when looking at e-books. Etsy is a great example of where the fees seem much more realistic, 20 cents per item listed and 3.5% sales fee. There is a business model that is working and doing much the same as Apple currently is with their App Store. Apple’s cut is so out of portion to everything else comparable is the real problem.
I’ll agree that this is defiantly a subjective claim as it’s hard to state what is and isn’t a viable or reasonable business model, and certainly Apple can charge a 30% or 5% or 90% fee and they are within their rights to do so. The argument can also be made, that a business shouldn’t bet their model on Apple treating them fairly cause that’s never a good idea, Apple defiantly does what is right for Apple. However if Apple doesn’t change their stance I can defiantly see Amazon just pulling out of the App Store and launching their service as a web app. It’s not the best solution for them, but it’s better than Apple taking every penny they make on e-books, especially when the competing smartphone platform takes only 5%.
Update, March 22nd, 2011: We’re thrilled to report that Amazon has reinstated our API access, and Lendle is back up and running. Welcome back, Lendlers!
Late today, we received an email from an Associates Account Specialist at Amazon informing us that their concern only relates to our Book Sync tool, which syncs a user’s Kindle books with their Lendle account. Amazon informed us that if we disabled this feature, our access to the API, as well as our Amazon Associates account, would be reinstated. We appreciate Amazon’s willingness to modify the original access revocation email and work with us to get Lendle back on line. We have complied with the request to disable the book sync tool (which was a very useful, but non-essential, feature of Lendle).
We’ve learned a lot through this process, and have come to realize we need to work towards a Lendle product that does not rely on APIs provided by Amazon or any other third party. To that end, we’ve already begun brainstorming the next version of Lendle. Suffice it to say, we’ll continue to make good on our promise to keep Lendle the easiest, fastest, fairest, and best way to lend and borrow Kindle books.
via Lendle – Amazon revokes Lendle’s API access Update. Let’s hear it, good job Amazon on getting in touch with Lendle and coming to a reasonable solution.
Amazon has revoked Lendle’s API access. This is why the site is down. It’s sad and unfortunate that Amazon is shutting down Lending sites.
via Twitter – Lendle – Amazon has revoked Lendle’s API access. It’s downright awful, Lendle was a great site where you could lend your Kindle books with people you wouldn’t even know. And the reason behind Amazon shutting down their account is lame:
According to Amazon, Lendle does not “serve the principal purpose of driving sales of products and services on the Amazon site.”
Lendle now has the full story posted.
Why are third parties important in the Twitter ecosystem?
Let Twitterrific count the ways:
via furbo.org – Twitterrific firsts. Third party clients have been at the forefront of the Twitter experience for many years, that differentiation and unique spin on the Twitter stream is what drove many of Twitter’s core functionality today. Apparently though that unique experience is what Twitter is trying to eliminate or at least control more.
In Google Chrome OS, all applications are web apps. Therefore, in designing the printing experience for Google Chrome OS, we want to make sure printing from web apps is as natural as printing from traditional native apps is today. Additionally, with the proliferation of web-connected mobile devices such as those running Google Chrome OS and other mobile operating systems, we don’t believe it is feasible to build and maintain complex print subsystems and print drivers for each platform. In fact, even the print subsystems and drivers on existing PC operating systems leave a lot of room for improvement.
Our goal is to build a printing experience that enables any app (web, desktop, or mobile) on any device to print to any printer anywhere in the world.
As we dig into type rendering on the web, we’ll begin by looking at text rendering engines. We are all familiar with operating systems like Windows and Mac OS X, but within each OS are smaller, specialized components available for use by applications like web browsers. APIs such as Core Text on Mac OS X, and DirectWrite and GDI on Windows, are examples of these components and are responsible for rasterizing fonts’ vector outlines. Let’s examine screenshots of web type as rendered by each of these APIs, and talk about the application independence of rendering engines.
via The Typekit Blog – Type rendering: operating systems. How does type get rendered on Macs (also iOS devices) and Windows and what is each platform aiming for?
Simple HTTP+JSON method of accessing a user’s information in a user approved sandbox on the user’s desktop. List, upload, delete, move, copy, and get files as well as many other features.
via Dropbox – Developers. This could be a really fun API to play with.