nrk.no

Spådom for 2009: Web hooks

Kategorier: Det sosiale nettet & Nettjenester

Eksempel på korleis Twitter kunne implementert Web Hooks

I januar-februar kvart år bruker eg å tenkje meg kva som vil bli den store trenden for nettapplikasjonar i det kommande året. I fjor var eg sikker på at geografisk relevante tenester kom til å blomstre, og eg hadde delvis rett (f.eks. Everyblock, NYTimes Represent, Brightkite [dekt i ein tidlegare sak] for å nemne nokon) – sjølv om Twitter endte opp med å bli tenesta med mest eksplosiv vekst.

I år har eg trua på at “web hooks” kjem til å bli stort, og eg skal prøve å forklare kvifor.

Tradisjonelle API-er

Mange av lesarane av denne artikkelen har heilt sikkert ei personleg side. Dei fleste har sikkert også ein konto på Twitter, Facebook, Flickr, Dopplr og fleire andre sosiale nettverk. Om du har eit publiseringssystem på sida di, fins det alltids ein måte å integrere desse tjenestene med resten av innholdet ditt. Dette gjerast ofte via ein API, som for eksempel ein RSS-feed.

For å ta eit praktisk eksempel: Kvar gong du oppdaterer Twitter-statusen din blir innholdet tilgjengeleg via Twitters API (i JSON-, RSS-, Atom- og normalisert XML-format). Sida di kan vidare sjekke API-en kvart x minutt, for å så oppdatere ein tabell i databasen din med eventuelle nye statusoppdateringer.

Dette virker kanskje som ein god måte å gjere ting på. Men kva om du ikkje oppdaterer statusen din på nokre dagar? Sida di kjem likevel til å fortsette å spørje etter nye innlegg, og Twitter kjem til å svare. I liten skala vil dette ikkje spele ei stor rolle for deg, men Twitter må ta i mot tusenvis av desse forespørslane kvart minutt, og det gjer fort at serverane til Twitter får litt å bryne seg på.

Eksempel på korleis ein tradisjonell HTTP Pull-API fungerer.
Eksempel på korleis ein tradisjonell HTTP Pull-API fungerer.

Hadde det ikkje vore mykje betre om Twitter fortalde nettsida di at du har oppdatert statusen?

Web hooks

“Web hooks”-filosofien går ut på at ein nettapplikasjon kan definere ein serie funksjoner for å gje beskjed til eksterne kilder ved spesifikke hendinger.

Ved å bruke HTTP Push er det opp til Twitter å gje beskjed om når oppdateringer har funne stad.
Ved å bruke HTTP Push er det opp til Twitter å gje beskjed om når oppdateringer har funne stad.

Sjå for deg følgande scenario (fortsatt med Twitter som eksempel): Kvar gong du oppdaterer statusen din, sender Twitter ei melding til webserveren din med informasjon om statusoppdateringa. Serveren din henter så ut det relevante av informasjon, og avslutter HTTP-tilkoplinga.

Twitter kan definere fleire «bøtter» som tar seg av forskjellige typer innhold (“direct messages”, replies, RT, etc..), slik at du som brukar får ein meir finmalt informasjonsstraum levert til deg.

Eksempel på korleis Twitter kunne implementert Web Hooks
Eksempel på korleis Twitter kunne implementert Web Hooks

For deg som brukar vil dette føre til at din informasjon vil vere betre synkronisert rundt om på nettet.

Kva trur du? Kjem “Web Hooks” til å bli ei stor trend i 2009?

12 kommentarer

  1. Blir ikke dette litt som Friendfeed sin åpne standard SUP ? Nettsteder som implementerer denne sier ifra til Friendfeed når de har noe nytt, også henter Friendfeed det på bakgrunn av den meldingen. Mange har tatt det i bruk (plugin for WP finnes) og ikke vanskelig å se at dette blir stort med den massive trafikken alle de hippe sosiale nettstedsaggregatorene kommer til å skape.

    Svar på denne kommentaren

  2. Magnus K S Andersen

    Da må det bli et økt behov for realtime videresending av data isåfall hvis dette skal bli veldig viktig. Datakraften og nettlinjekapasiteten blir vel bare enda større i 2009 slik at dette ikke blir noe stort problem.

    Svar på denne kommentaren

  3. Henrik Lied (NRK)

    @ThomasB: Jo, FriendFeed er vel kanskje den applikasjonen som har hatt størst fokus på Web Hooks i 2008, men eg skulle gjerne sett det frå f.eks. Facebook, Flickr, Twitter og dei andre store nettverka. Eg veit at Friendfeed og Twitter har eit ganske spesielt forhold, og at Twitter faktisk sender alle tweets i realtid til FriendFeed (dog via XMPP, som er ein annan framgangsmåte).

    PayPal har jo gjort dette i årevis. Kvar gong du betaler for ei vare via PayPal sender PayPal ei melding tilbake til selgerens server med ein bekreftelse, og dette er akkurat den type kommunikasjon eg håper at vi får sett meir av framover.

    @Magnus K S Andersen: Vi ser allerede at dette behovet har blitt større, nettop gjennom populæriteten Twitter har fått i det siste. Flykrasjet i Hudson er eit godt eksempel på dette. Det samme gjeld Facebooks «Live Feed».

    Svar på denne kommentaren

  4. Sebastian Steinmann

    Dette blir vel noe av det samme som pingbacks.
    For at Twitter for eksempel skal gidde å implementere noe slikt må det finnes applikasjoner som kan benytte seg av dette.

    Ser nok for meg sider som kommer til å samle dataene istedenfor å sende direkte til sin applikasjon..

    Svar på denne kommentaren

  5. Hvis jeg ikke tar helt feil, bør et subset av Atom Publishing Protocol (APP, RFC 5023) være velegnet for dette?

    Problemene oppstår vel gjerne hvis man skal ha noen form for leveringsgaranti. Hvis du er bruker B, og bruker tjenesten T (f.eks. Twitter) og vil ha en «web-hook» fra applikasjon X, får du flere muligheter:

    1. Når B sender til T, vil T øyeblikkelig kontakte X for å levere meldingen videre. Dersom X ikke svarer, vil T svare med en HTTP 5xx- eller 6xx-feilmelding til B. Meldingen er altså ikke godtatt dersom X er nede.

    2. B sender til T, og T godtar meldingen med en gang (HTTP 2xx). T vil legge meldingen til X i en kø og gjøre gjentatte forsøk på levering til X, helt til meldingen faktisk blir levert eller det har gått f.eks. 4 døgn. Dette er løsningen som likner mest på SMTP (mail), som vi alle kjenner problemene til…

    3. B sender til T, og T godtar meldingen med en gang (HTTP 2xx). T vil så forsøke å levere til X, men vil gi opp dersom X ikke svarer. X må selv kontakte T (hente på vanlig pull-måte) for å sjekke om det er noe som ikke har kommet frem.

    Egentlig tror jeg bare alternativ 3 er realistisk. Alternativ 1 vil få T til å virke ustabil, selv om feilen ligger hos X. Alternativ 2 blir altfor dyrt, særlig i systemer som oversvømmes av spam.

    Man ender da opp med å kunne redusere antall GET-forespørsler mellom X og T fra f.eks. hvert 15. minutt til kanskje hver N-te time, eller til og med bare en gang i døgnet. Men kompleksiteten hos både T og X øker ganske mye…

    En enklere løsing er pingbacks, som bare sier «nå er feeden min endret, sjekk den med en gang». Altså alternativ 3, men uten selve innholdet i meldingen fra T til X. Det gir ganske liten ekstra kompleksitet, og vil gi like gode muligheter til å redusere frekvensen på forespørslene. Det brukes jo av en del blogger i dag, så det finnes ganske noen gode standarder?

    Det hadde også vært koselig med en standard måte for automatisk abonnering på pingbacks for en feed. F.eks. at du oppgir til X at applikasjonen din skal bruke en feed fra T. X ser at feeden inneholder en «kan abonnere på pingbacks»-tag, og kontakter så T på en standardisert måte for å be om pingbacks når den aktuelle feeden endres. Da kreves det minimalt med GUI-endringer i eksisterende applikasjoner. 🙂

    Jeg nevnte forresten spam her… Web-hooks med innhold vil jo få utfordringer med spam. Nå har vi fordelen at siden du vet hvilke tjenester som skal sende data til applikasjonen din, så kan du autentisere disse og nekte adgang til alle andre. F.eks. ved at tjenesten signerer alle push-meldinger (altfor dyrt i praksis), eller ved at push-adressen inneholder en hemmelig nøkkel (/GET_TIMELINE/?key=jknb7g99uhoij-9j). Men da har vi dette med kompleksitet og brukervennlighet igjen…

    @Sebastian Steinmann: Tenker du sider som henter feeds og genererer push-meldinger til andre applikasjoner? Jeg tror egentlig få vil gidde å bruke en slik «mellommann» når det er enklere å la applikasjonene hente feeds direkte… Det er jo tjenestene, som Twitter, som har noe å tjene på dette. Da er det også der initiativet må tas.

    Svar på denne kommentaren

  6. @Simen: Takk for eit fyldig innlegg!

    RFC 5023 er jo delvis forfatta av Bill de Hora, som lenge har vore ein forkjempar for Push-baserte løysinger. Eg ser derimot på løysinger som XMPP og denne som «industrial grade», om det gjev meining, og ikkje som naudsynt for sosiale nettverk som først og fremst har Ola Nordmann som målgruppe. Eg kan leve med at ei statusoppdatering eller to frå Twitter-straumen min forsvinn i prosessen.
    Og likevel – sjølv den enklaste form for “web hook” vil bruke eit asynkront meldingssystem for å levere beskjedane, rett og slett fordi det blir for intensivt for store nettsamfunn å køyre oppdateringane direkte ut i frå webserveren – spesielt når det fins løysinger som er betre egna for jobben (som f.eks. Beanstalkd og Gearman), og da har ein lett moglegheita til å setje ein «retry»-periode på f.eks. 20 forsøk.

    Men eg forstår likevel godt kva du meiner. For “viktige” tenester er det naudsynt at datatap er lik null, og då er det tyngre protokoller som må inn i biletet. Likevel – PayPal har klart seg ganske godt med ein veldig enkel form for “web hook”, så eg vil tippe at det er innanfor rammene til dei fleste andre prosjekt. 🙂

    @Sebastian: Dei fleste av applikasjonane som innretter seg mot filtrering av oppdateringer på Twitter hadde nok vore veldig interessert i ein Push API. Eller misforstod eg kva du ville få fram?

    Svar på denne kommentaren

  7. Alexander Nossum

    Helt klart at «web-hooks» er noe web-applikasjoner virkelig trenger. Ideen er egentlig ganske gammel i «old-fashion» programmering – da er det kalt Observer Pattern [Gamma et.al] (en.wikipedia.org/wiki/Observer_pattern).

    Paradigme om at man må spørre eksplisitt om «har det skjedd noe» er dårlig på mange måter. Blant annet;
    1. Unødvendig nettbruk
    2. Dårlig software design
    – Øker koblingen uten å øke koherensen

    SOA o.l. har jo for sluttbrukeren «løst» problemet med å aggregere flere tjenester sømløst, men over HTTP er det enda et problem å få til gode Observer Pattern-lignende løsninger. Men ideen skissert her er jo en, og muligens god – håper inderlig dette blir en trend for web-app’er framover!

    Btw; god artikkel!

    Svar på denne kommentaren

  8. henriklied (NRK)

    Som eg nevnte i kommentaren ovanfor ser eg på XMPP og Atom Publishing Protocol som protokoller av eit litt større kaliber.

    Tanken bak enkle HTTP callbacks er at alle og einkvar med eit 20kr/mnd webhotell skal kunne kjøre eit system som dette uten problemer. Det får du ikkje til med XMPP, Jabber og Atompub.

    Svar på denne kommentaren

Legg igjen en kommentar til MediaFront (MediaFront) Avbryt svar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *. Les vår personvernserklæring for informasjon om hvilke data vi lagrer om deg som kommenterer.