MatrixAdapt | Logiciel de gestion d'Entreprise, Création et référencement des sites web

Seo Master present to you: This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. Today's post is a guest post written by Steven Willmott of 3scale.

Public APIs are a great way to share data and functionality, both for existing applications and as useful resources in their own right. Google Maps, Calendar and many other APIs lead the way in this and are now powering tens of thousands of sites and applications. Flickr, Twitter and others also provide great data and functionality which can be used to enhance and build new applications.

While APIs can provide great value add, it's not always obvious how to make one available if you're not Google or Yahoo. Although serving content via an API is effectively no different than via a user-facing web app - just serving HTTP traffic with XML, JSON or arbitrary data rather than HTML, CSS and Javascript normally destined for a browser - it does come with some unique challenges: authentication works differently, inbound traffic is often automated and response times need to be rapid for the API to be usable within another site - all a bit different from a standard web app.

Since we're in the API business we often get asked about how to quickly get a new API up and running, and one neat new way to do this is using Google App Engine, which provides a lot of the core ingredients needed to launch a new API and help it scale. To see how this works we put together a quick and dirty trial service which exposes App Engine's Image manipulation functions as a new Web API:

1. First we set up a standard App Engine account giving us the standard dashboard and deployment environment. This provides the runtime environment plus a range of tools to monitor the application - all useful to track resource usage which we'll need to worry about later.


2. The service itself in this case is a simple wrap of wrapping App Engine's available image manipulation features which provide standard image manipulation features, but it could easily be more complex.


3. Next up, the functionality is wrapped in a simple RESTful interface. There are multiple ways to do this, libraries such as the App Engine Rest Server and the Django rest interface or a port of the Ning-like REST interface can be used to do most of the heavy lifting. Gae-Rest for example includes indexes and memcache and other features to optimise response times on the API. These give the API standard GET, POST, PUT, DELETE operations we'll need to push images in and out of the application.


4. Finally, while we have the service ready to roll we still need a way for developers to access the service, manage their resource usage and track activity on the API. To do this we can use 3scale's API management platform which provides these features out of the box. Connection works using a standard python plugin and the system creates a configurable management portal for the service which handles signup keys, usage limits, traffic analysis and the documentation needed to support developers using the new API. For heavy users we can also add paid plans to cover any App Engine costs or make a small profit - check out the appspotimage portal here:

The service can now take advantage of App Engine's scalability - even under the constraints of the plan, your API should comfortably serve up 500,000 - 1 Million hits per day (although note that you need to check other resource limits - not just hits) which would be non-trivial to arrange and potentially high cost on a lot of existing hosting services. If you're serving traffic from appspot.com (for appspotimage we serve the management interface from appspotimage.com and the API traffic from appspot.com) response times from App Engine tend to be very fast (sub 10ms if you're on the west coast US) - which is great for API users.

Although backend APIs are not quite as visible as a new Android or iPhone App, they often provide a great resource and hopefully we'll see more and more datasets and new types of processing on line as APIs.

You can find the service itself here along with a longer tutorial on how we built it. Stay posted for some other services coming soon, as we start to play around with Java language support on App Engine.

We'll be at Google I/O on May 27-28 and look forward to talking APIs and App Engine, so stop by the Developer Sandbox. See you there!

Guest Post by Steven Willmott of 3scale2013, By: Seo Master

Seo Master present to you:
By Scott Knaster, Google Developers Blog Editor

As regular Fridaygram readers know, at Google we love to get students involved in coding and other pursuits. For example, last fall we announced the Google Photography Prize, which was open to student photographers around the world. More than 20,000 students from 146 countries submitted entries in the few months the competition was open.

A panel of judges whittled these entries to 100, and then to 10 finalists. You can read more about the competition and see a slideshow of the amazing work of these photographers.


Let’s move from still photos to video – and out into space, with a look at what video creator Alex Rivest calls "the best view in the solar system". This video shows what astronauts see from the International Space Station, from various points of view. When you watch this video, you can really see what Alex means. And it kind of makes you want to go check it out for yourself.

As long as we’re already out in space, we can’t resist a final mention of one of our favorite Fridaygram topics, the U. S. Space Shuttle. Earlier this week, shuttle Discovery was flown to its new home at the National Air and Space Museum in Washington, DC, producing some incredible sights before arriving. Happy retirement, Discovery.


On the land or in the sky, Fridaygram posts are just for fun. They're designed for your Friday and weekend enjoyment. Each Fridaygram item must pass only one test: it has to be interesting to us nerds.

2013, By: Seo Master

Seo Master present to you: As we announced in the last update to the former orkut Developer Blog last week, henceforth we’ll be posting all orkut developer updates to this blog.

We think this is also a good opportunity to quickly introduce the newly-launched Developer page to you. We recently added this feature to the orkut sandbox which we hope to be a one-stop solution for developers looking to manage their applications from a single page and view their stats. You can submit your apps directly from here and verify them to complete the submission process. You can also maintain your apps from here and migrate them to a new URL, or delete them entirely from the directory. And if you have applications that have already been approved and included in the directory, expand their details to track the number of installs, uninstalls, renders and other useful stats updated every week.

Here’s what it looks like in action:


Please note that the Developer page requires you to be on the new orkut UI to work.

So keep your apps coming and point your browser to the one page to manage them all: sandbox.orkut.com/Main#Developer. And stay tuned for all orkut updates right here on the Google Code Blog!

By Prashant Tiwari and Ridhima Kedia, orkut Team
2013, By: Seo Master