Webbens Arkitektur

Preview:

DESCRIPTION

Slides in swedish from a presentation I held at Valtech Days 2009 on the architecture of the web. I discus HTTP, resource and service application design.

Citation preview

Webbens arkitektur

Delade ytor, oberoende djup

Tema

Webben som plattform.

● Nätverk av resurser● Öppna format● Uniformt API

Hållbarhet (skalbarhet).

Innehåll

● Identifikation● Representation● Form● Funktion

● Komposition● Feeds● Maskineri

Vem?

Niklas Lindström, Valtech<niklas.lindstrom@valtech.se>

Det kommer attbyggas om.

Bygg förombyggbarhet.

Syfte

Material — förstå vad som är:

● fasta delar● klister

Ändamål

Kunna:

● byta utseende● koppla ihop med andra webbapplikationer● byta ut indexering/sökmotor

— utan att redigera om alla artiklar!

Strategi

Hållbara ting med:

● tydliga former● entydiga relationer

Föränderliga funktioner.

101

Obs! Detta är fundamentet.

Rika klienter/-beteenden byggs med fördel ovanpå detta.

2 sekunder historia

Internet: nätverk av datorer

Webben: nätverk av dokument

En webbplats är

En samling pusselbitar.

Kombineras med andra pusselbitar "hur som helst":

● länkning!

"Startsidan"

En mötesplats. Skyltar.

Ingen webbplatsbehållare.

Beständiga delar

Primära resurser:

● har en eller flera representationer● kan visas i: vyer/tjänster (virtuellt)● samverkan: länkar

Exponera vad du har, inte hur du åstadkommer det.

Tänk i resurser

● de primära byggblocken● det som ska vara beständigt● dessa länkas samman

.. samlingar/kategorier är också resurser.

Ordnade behov

1) Användning, bestämmer form på..2) Data, som används av..3) Funktioner, vilka underlättar #1.

Identifikation

Namn

URI:er är namn på resurser.

Kan hämtas: HTTP

URI:n är

Nyckeln i strategin.

För beständighet: mynta hållbara namn.

Hållbara namn

En webbsidas publika namn — URI — ska hålla lika länge som sidan själv.

Åratal? Decennier?

Intern-ID eller "sammansatt nyckel"?

Ska vara intakta efter byte av:

● datalager● publiceringsplattform

Finns behov av förutsägbarhet?

Namnsammansättning

Domännamnet = grundläggande kontext.

● typ● ursprung (publiceringskälla)● datum● "primär etikett" (titel/namn..)

Mindre bra

http://example.com/publisher.jsp?article=x123

http://examplecom/CMSVendor/display_product.aspx?oid=23779&viewstate=list&format=html

● irrelevant information● hårdkopplad till underliggande lösning

Bra URI:er

http://example.com/book/23779 http://example.com/book/23779.html http://example.com/book/23779.json

http://example.com/books http://example.com/books.html http://example.com/books.atom

http://example.com/book/23779/related

Representation

Primära resurser

● Digitala verk (ren information, olika mediaformat)● Saker i världen● Koncept (kategori, grupp, modell, ...)

Virtuella resurser

Vyer, t.ex.:

● expanderad information (relaterade ting)● "dekorerat"● kompositioner● genererade format/responser

Tjänster? Resultat.

● sökningar, filtreringar● sammanställningar

Dokument

Inneboende egenskaper:

● ariklar, personer, produkter● {titel, datum}, {namn, roller}, ...● relationer: namngivna länkar!

Listor

● titel, typ, ...● Länkar till dokument.● Paginering: länkar till andra listor.

Tjänster

Parameteriserade resurser.D.v.s genererade dokument.

Allt detta kan ha URI:er

Kan hämtas.

En del av dem kan också:

● uppdateras● raderas● "ta emot data"

Form

Hypertext

Syntax:

● HTML● XML● JSON

Modeller

● HTML: XHTML 1, HTML5● Atom: feed-format (med plats för nya

egenskaper och relationer)● JSON: sparsam semantik● RDF: DC, FOAF, SIOC, CC, SKOS, OWL, ...

API för virtuella resurs-URI:er

HTML-formulär!

● parametervärden för parameteriserade resurser● posta "paket" som kan bli nya resurser

.. WADL..

Ekonomisk

Var "upplyst lat".

Återuppfinn ingenting i onödan.

Överlevnad

Permanent Objects, Disposable Systems

[The California Digital Library, Maj 2009]

System kommer och går..

"Now here is the curious thing. There is so much data available on Web pages, that there is a market for tools that 'reverse engineer' that process."

"These are tools that read pages, and with a bit of human advice, recreate the database object."

[Tim Berners-Lee, 1998]

Google

Varför klarar sig google så bra?

● De har koll på sin data.● De har koll på DIN data..

Funktion

REST

Det uniforma API:t.

● GET● POST● PUT● DELETE

Hypertext as the engine of application state.

HTTP

Åtkomst/transport.

Protokollet är:

● enkelt● tillräckligt

Content negotiation

curl -L -H Accept:application/xhtml+xml \ http://example.org/about

...

HTTP/1.1 200 OKContent-Location: http://example.org/about.xhtml

Komposition

Din resursarkitektur

● Vad är primärt?● Vad är beräknat (vilka parametrar)?● Vilka externa resurser ("tjänster") vill du

använda?

Hur bygga ut?

Vad beror dina resurser på:hur många lådor på rad / i hög?

Vad beror dina funktioner på:hur mycket sladdar i lådorna?

Databasmotorer är optimeringar!

Gör inte ditt material beroende av dem.

Dina värdeskapande tjänster däremot..?

● kan förändras på alla möjliga vis!

Case: indexering

"Sökmotorer"En tjänst på din information, inte på ditt maskineri.

● bland dina egna virtuella resurser● google, yahoo, siteseeker...

Hur är indexeringen integrerad?

● Hur tar den emot dina resurser?● Hur serverar den dem?

Länkar!

● Format: uniformt nog att vara utbytbar?

Våga pröva nytt

Bygg inte allt i samma låda.

Använd andras lådor:

● statistik● kommentarer, feedback● bilderböcker, länksamlingar

RO över ån efter vatten?

Indexera dig själv!

Fristående webbapplikationer för olika delar av samma webbplats.

.. Men tänk på komplexiteten.

Separation

Enkelt är bättre än komplext.

Komplext är bättre än komplicerat.

"Hur mkt sladdar i lådorna?"

Feeds

Feeds

Det är fantastiskt hur mycket man kan göra med feeds!

● en resurs som listar resurser.

För alla behov

PrimäraRepresenterar en "behållare".

VirtuellaSökresultat (kategorifilter, "sökord" ..)

Paginerade resurslistor

Länkar till andra listor (andra tillstånd).

● nästa● föregående

Representationer

En resurs, flera format:

● kategorisida (html)● feed (atom)

<head> ... <link rel="alternate" type="application/atom+xml" href="/categories/article,tech/feed.atom" />

</head>

Atom

<feed xmlns="http://www.w3.org/2005/Atom">

<id>http://spreadsheets.google.com/feeds/.../full</id> <title type="text">Available Spreadsheets - somebody@...</title> <updated>2009-10-21T16:12:37Z</updated>

<link rel="self" type="application/atom+xml" href="/feeds/spreadsheets/private/full"/> <link rel="alternate" type="text/html" href="http://docs.google.com"/>

<entry>...</entry> <entry>...</entry> ...

</feed>

GData<entry> <id>http://spreadsheets.google.com/feeds/.../o1234.1</id> <category scheme="..." term="...#spreadsheet"/> <author> <name>somebody</name> <email>somebody@gmail.com</email> </author>

<title type="text">Mötesplanering 1</title> <updated>2009-10-21T16:12:37Z</updated> <content type="text">Mötesplanering 1</content>

<link rel="alternate" type="text/html" href="/ccc?key=o1234.1"/> <link rel="self" type="application/atom+xml" href="/feeds/spreadsheets/private/full/o1234.1"/> <link rel="...#worksheetsfeed" type="application/atom+xml" href="/feeds/worksheets/o1234.1/private/full"/></entry>

Länkad data på webben öppnar upp enorma möjligheter.

Initiativ med momentum idag:

● Atom (OpenSearch, GData, AtomPub, CMIS..)● Yahoo och Google indexerar microformat,

RDFa..● Dataliberation.org (Google)● TBL: "Open Data Now!"

Open Government Data Now!

● US: data.gov● UK: data.gov.uk● Australien: data.australia.gov.au

På gång:

● Sweden: opengov.se, e-delegationen..● med mera!

Maskineri

Klister

Instrumentellt.

Kolosser"Men den är julättanvänd."

Lättviktigaramverk

Django, Rails, Grails, ...

● Tämligen tunna lager.● Principiellt enkla att anpassa, utöka, kombinera

med annat, bytas ut.● Specar inte mer än nödvändigt för att servera

resurser.

Tunna lager

Nära mellan databas och http — för det primära.

Tydligt

Lätt att se vad som knåpas ihop till en resurs:

● primär data● associationer● funktioner

Håll det enkelt

Bygg inte "på djupet": koppla resurser så direkt som möjligt.

En komplex, avancerad inre arkiktektur..

● Är mindre relevant än resursarkitekturen.● Hög risk om ytorna är direkt beroende av

(plattformstekniska) detaljer.

Spaghetti är spaghetti

● Högnivåkod kan också bli hopplös att underhålla!● Om det växer oregerligt — frångår webbens

principer..

Tillämpning

Se till att din URI-rymd:

● kopplar till resurser● är lätt att åstadkomma● är lätt att använda

Låt inte plattformen styra!

Enkelhet, tunnhet

● objekt   — [relation] →   objekt● dokument   — [länk] →   dokument

Hur ska det kännas?

Som om lösningen består av små, tydliga recept (för resurser).Där webbsidor bakas ihop av:

● primär resursdata● funktioner på data● listor ur index

Och sedan kläs i presentation (mallar).

Speca

(Webbtestramverk: Selenium, Windmill, Twill, Cucumber, http-bibliotek...)

Körbara specar som dokumentation på API:t!

Tydliggör vad som är:

● form● beteende

Ortogonalt

I protokollet (HTTP):

● överföring (inkl. checksummor)● autentisering (identitet)● kryptering (SSL)

I data: rättigheterPå data (format-beroende): signering

Summering

Webbens arkitektur

● Identifikation: URI:er● Representation: öppna format, länkad hypertext● Åtkomst: HTTP● Funktion: REST● Komposition: länka alla slags resurser

Recept för hållbarhet.

Tack!