Jarmark.org

Nie wiem czy web2.0 się już zestarzało i odeszło (zgodnie z sugestywną prezentacją Marcina na ostatnim bootstrapie), czy też dopiero wchodzi w wiek nastoletni. Faktem jest, że wraz z wysypem serwisów ometkowanych jako webdwazerowe pojawiła się także moda na udostępnianie funkcjonalności serwisu lub jej części przez API. Krok ten dla większości serwisów to bardziej próba wykorzystania potencjału developerów żyjących gdzieś tam hen, hen w fałdach długiego ogona niż decyzja podyktowana realnymi potrzebami klientów/użytkowników serwisu, ale zjawisko przybiera na sile. Nie jest to w żadnym razie krytyka z mojej strony - raczej obserwacja. Trudno nie zauważyć, że ta moda na API umożliwiła powstanie wielu serwisów nadających nowe znaczeniu słowu ‘integracja’. Inna sprawa, że przytłaczająca większość tych serwisów nie prezentuje zbyt wielkiej wartości nawet jako oprogramowanie - nie mówiąc już o biznesie. Właśnie ten ostatni aspekt zainteresował mnie szczególnie.
Przejrzałem API kilkunastu serwisów (oraz warunki korzystania z nich) zastanawiając się czy twórcy serwisów starają się budować jakieś przychody związane z korzystaniem z API, czy tylko jest to objaw swoistego developerskiego ekshibicjonizmu :)

Warunki korzystania z większości z dostępnych API pozwalają na ich używanie bez ponoszenia żadnych kosztów. Czasem z dodatkowym zastrzeżeniem niekomercyjnego charakteru gotowego rozwiązania (głownie API Google’a). Ciekawie wyglądają sposoby ograniczenia i kontroli wykorzystania API:

• ograniczenie liczby wywołań w jednostce czasu dla jednego klucza dostępowego np. 50 tys. wywołań dziennie w Goolgle Maps API,
• minimalny czas jaki musi upłynąć między kolejnymi wywołaniami np. w del.icio.us API między kolejnymi wywołaniami musi upłynąc przynajmniej 1 sekunda,
• ograniczenie liczby wywołań z jednego IP na dobę np. 5000 wywołań dla jednego IP w ciągu doby w większości API udostępnionych przez Yahoo,
• ograniczenie liczby wywołań w jednostce czasu i maksymalna liczba wywołań np na miesiąc,
• ograniczenie wielkości zwracanego zbioru danych,
• ograniczenie transferu.
  

W przypadku płatnych API natknąłem się na następujące modele:

• hurtowa opłata za N wywołań np. Alexa Web Information Service
• opłata za transfer danych np. Amazon Simple Queue Service (choć tu połączona jednocześnie z opłatą za wywołanie)
• opłata za wykorzystanie wirtualnych jednostek zużywanych przez każdą wywoływaną funkcję API (wielkość tego zużycia jest zależna od zasobochłonności danej funkcji) - ten model jest wykorzystywany przez API Google AdWords

Warto zauważyć, że większość odpłatnych API to zestawy funkcji bardziej generycznych (zwanych też z webservice’owego usługami), niezwiązanych z możliwościami konkretnego serwisu, a raczej dające uniwersalne możliwości do wykorzystania w tworzonej aplikacji. Podpada to oczywiście pod kolejne popularne buzzwordy: SOA (service oriented architecture) czy SaaS (software as a service). Przyznam jednak, że po przejrzeniu usług oferowanych przez firmę Strike Iron przyszło mi do głowy kilka sensownych zastosowań w których oferowane przez nich funkcje miałyby szanse na siebie zarobić.

Zastanawiam się jeszcze czy darmowość API poszczególnych serwisów jest podyktowana tylko chęcią likwidacji bariery wejścia dla developerów… A może jest to objaw pewnego braku na rynku - gdyby tak istniał pośrednik owijający API do naszego serwisu w obsługę płatności i realizujący za nas wybraną strategię limitowania/kontroli dostępu do API? Pośrednik taki utrzymywał by się z prowizji, a właściciele serwisów mielimy coś więcej poza AdSense. Może w tym kierunku rozszerzy swoje działania Dapper - ich plany rozwoju wyglądają dosyć podobnie (choć narazie dotyczą zawartości serwisów nie ich API).

Postanowiłem jeszcze rzucić okiem na nasze podwórko. Jest słabo, oj słabo - lista serwisów udostępniających API jest bardzo krótka (kolejność przypadkowa):

• allegro.pl - WebAPI
• swistak.pl - cieżko nazwać to API ale zaliczam,
• blip.pl - projekt w fazie beta ale już coś jest Blip API,
• serwisy obsługujące płatności - choć w ich przypadku jest to raczej podstawowa metoda działania,
• grono.net - było apidoc.grono.net ale nie ma, może to chwilowe?
• Aktualizacja: spinacz.pl opis API na wiki serwisu
• coś jeszcze?

Żaden z serwisów nie prezentuje też swojego API w sposób choćby zbliżony do wzorcowej pod tym kątem strony dla developerów Facebook API. Mam nadzieję, że przeoczyłem jakieś serwisy, jeżeli tak chętnie rozszerzę powyższą listę…