SOSYAL PLATFORM API’LERİ

Ön BilgiNeden API Sunulmalı?

Kullanım AlanlarıÖrnek Platform API’lar

OAuthPlatform API Tasarlamak

8 Günah3. Parti Uygulamalar& Sektör

Ahmet Alp Balkanwww.ahmetalpbalkan.com

1

API

• Geliştirici için arayüz.

2

Neden API Sunulmalı

• Geliştirici komünitesini uygulama geliştirmeye teşvik

• Uygulamanın farklı platformlarda sunulabilmesi için esnek bir yapı

• API ile düşünmenin getirdiği kod kalitesi

• İnsani test gücü

3

Kullanım Alanları

• Servislerin web-mobil istemcilerini geliştirmek

• Üçüncü parti uygulamalara yol açmak

• Açık verinin sunulabilirliğini sağlamak

• Projeler arası entegrasyon ve ortaklarla iş birliği

4

Twitter API

• Tweet yollama, silme, feed okuma, anlık-günlük trendler

• Onlarca mobil ve masaüstü client

• Rate limiting,Whitelisting

• Twitpic,@semwc, Twitter-Archive

Kaynak: cbinsights.com

5

Facebook API

• Bir çok işlem gerçekleştirilebiliyor

• Karmaşık dokümantasyon; iyi komünite desteği

• Sık sık devre dışı kalıyor – ilginç bug’lar var

• Facebook Connect OAuth 2.0

• Verimli FOAF (friend-of-a-friend) verisi

• IFrame içinde uygulama çalıştırma <-> FBML

Kaynak: cbinsights.com

6

YouTube API

• Video arama, yükleme, playlist işlemleri, video player API.

• 500+ mashup

• Fizy, playalike, Celebrity Sexy Video Finder

• Resmî Java, .NET, PHP, Python and Objective-C Kütüphaneleri

• Developer Key

7

Google Maps API

• 7.000+ mashup

• Developer key, JS-Server Side

• Taksiyle, foursquare, İBB Trafik…

…

8

FriendFeed API

• Görülen her veri API üzerinde var.

9

Kullanıcı Yetkilendirme Yöntemleri

• Kötü fikir: Kullanıcı adı-şifre

• Uzak anahtar (remote key)

• Gizli anahtar (secret key)

• OAuth-OpenId

10

OAuth: Sosyal Ağlar için Uygun Yöntem

• 3 aşamalı yetkilendirme

• Access key, Access token, Private key.

11

API Tasarlamak-I

• API içeriği kararlaştırılmalı (use-case)

• Convenient yöntemler takip edilmeli.

• Mutlaka JSON ve XML sunuluyor olmalı.

• Mümkünse DTD tanımına sahip olmalı.

• RESTful API olmalı. (SOAP vb. değil!)

• API sorgu frekansı takip edilmeli

• Güvenli yetkilendirme (OAuth) yapılmalı.

12

API Tasarlamak-II

• Backwards-compatibility sunulmalı.

Yeni API sürümü çıksa dahi eskisi desteklenmeli.• You can always add,but you can never remove.

1

• Gereksinimleri karşılamak için yeterince güçlü olmalı.

• Uygulamayla birlikte geliştirilmeli.

• Sunulan veriler OOP paradigmasındaki Entity’ler gibi ve ilişkisel sunulmalı.

13

API Tasarlamak-III (dokümantasyon)

• Sınıf ve metodlar tutarlı isimlendirilmeli.

• İsimlendirme zorluğu = kötüye işaret1

• Parametre listesi tüm detaylarıyla yazılmalı

• Parametre girdi biçimleri katı (strict) olarak belirtilmeli. RFC’lerle, Reg. Ex.’lerle... 1 2

• Kolay kullanılabilmeli (dokümantasyonsuz bile)

• Yanlış kullanılması zor olmalı.

• Hata durumları açıkça belirtilmeli. 14

API Tasarlamak-IV (kullanılabilirlik)

http://myapp.com/getCommentsByUser?user=foo

http://myapp.com/user/foo/comments

• Anlamlı HTTP/1.1 Status Code’lar kullanılmalı• 200 OK• 404 Not Found• 401 Unauthorized• 500 Internal Server Error

• Sıkıştırılmış (minified) ve girintilenmiş (pretty indentation) çıktı seçeneklerini sunulmalı.

15

API Tasarlamak-V (dokümantasyon)

• Hedef kitle tarafından anlaşılabilir olmalı.

• Örnek kullanımlar içermeli.

• Olası örnek yanıtlar içermeli.

• Mümkünse metodların demolarını içermeli. (API explorer) 1

• Precondition, postcondition’lar varsa belirtilmeli.

16

API Tasarlamak-VI (destek)

• API kullanıcılarının tartışabileceği komüniteler kurulmalı: Google Groups

• API önerileri-şikayetleri için bir e-mail.

• Güncellemeler ürün blogunda yayımlanmalı.

• Uygulama geliştirmeye teşvik edici örnek uygulama ve kod parçaları.

• Resmi ve unofficial hazır kütüphaneler

17

8 Günah

• Sürpriz hataları idare edememek

• Kötü komünite yönetimi

• API’yi subdomain altında yayımlamamak.

• Real-word testlerden yoksun olmak.

• Rate limit uygulamamak (+status page)

• Kötü hata mesajları

• Black-box testleri yapmamak

• API’yi ana faaliyet alanı olarak görmemek.

Kaynak: RWW18

3. Parti Uygulamalar

• Her zaman bir ayağı çukurda!

• FriendFeed: 60 servisten aggregation

• Platformun potansiyelini arkasına alır

• Platforma güç ve renk katar

• Twitter API > Twitter.com

19

Mash-up Pazarı

• Twitter odaklı uygulamalara 2008’de $19M, 2009’da $23M yatırım.

• Bit.ly: URL kısaltma $2M yatırım

• Tipjoy: Batık sosyal payment: $2M yatırım

• Tweetdeck:Gelişmiş twitter client’ı $3.5M yatırım

• Seesmic: Facebook, Twitter vb. client'$12M yatırım

• StockTwits: Finans takibi, tartışması: $4.5M

• TweetPhoto: $2.6M yatırım

• TwitPic: $10M’ı reddetti, $1.5m yıllık kâr.

Kaynak: ChubbyBrain20

Mash-up Pazarı

• “Are You Interested” (Facebook) 2008’de $1.5M kâr. 13M kullanıcı.

• Zynga (Facebook’tan) $40M kâr(2009)

• “Friends For Sale” $4M yatırım

• Facebook Platform uygulamaları

2009’da toplam $500M kâr.

21

Further Reading

• How to design Good APIs and Why they Matter (Joshua Bloch @ Google)

• Why API As A Strategy?

• Creating a new API [ 1 - 2 ]

• connect.microsoft.com

• How to Add an API to your Web Service

• www.3scale.net API management tool ($)

22