50Teknologi

Postels lov

Vær konservativ i det, du sender, og liberal i det, du accepterer — for mere robust kommunikation mellem systemer.

Kort fortalt

Postels lov — også kaldet robusthedsprincippet — siger: vær konservativ i det, du gør (send velformateret data), og liberal i det, du accepterer fra andre (tål variation, når det er sikkert).

Hvad betyder princippet?

Jon Postel formulerede princippet i forbindelse med tidlige internetprotokoller. Målet var interoperabilitet: systemer skulle kunne samarbejde trods små afvigelser, uden at sende rod videre.

I moderne API- og integrationsarbejde betyder det typisk strenge, klare responses — og fornuftig, dokumenteret tolerance i parsing, hvor det ikke skaber sikkerheds- eller konsistensproblemer.

Send rent. Læs tålmodigt — men ikke naivt.

Et konkret eksempel

En tjeneste accepterer tidsstempler med og uden tidszone i input, men normaliserer og udsender altid ISO-8601 med UTC. Partnere med lidt forskellig implementering kan tale sammen, uden at output bliver sløset.

En browser er historisk tolerant over for fejlbehæftet HTML. Det øgede udbredelsen — men skabte også et økosystem, hvor dårlig markup overlevede. Tolerance har omkostninger.

Hvornår er princippet nyttigt?

  • Når systemer skal interoperere på tværs af leverandører.
  • Når man designer protokoller og API’er.
  • Når stram afvisning skaber unødvendige brud.
  • Når man balancerer robusthed og strenghed.

Begrænsninger og kritik

Senere kritik peger på, at for liberal accept kan cementere fejl, skabe sikkerhedshuller og gøre adfærd uforudsigelig. I sikkerhedsfølsomme domæner er “fail closed” ofte bedre.

Postels lov er et robusthedspejlemærke for kommunikation — ikke en blankocheck til at acceptere alt.

Kilder

  1. Jon Postel — robusthedsprincippet i tidlige RFC’er om internetprotokoller.
  2. Bemærkning: Princippet er klassisk i netværksengineering og fortsat diskuteret i API-design.
  • 23Galls lovKomplekse systemer, der virker, er typisk vokset ud af simple systemer, der virkede — de designes sjældent færdige fra scratch.
  • 34KISS-princippetHold løsninger så enkle som muligt — kompleksitet bør være begrundet, ikke standard.
  • 39Loven om utætte abstraktionerAlle ikke-trivielle abstraktioner lækker: før eller siden må man forstå lagene under for at fejlsøge eller bruge dem korrekt.
  • 14DRY-princippetDon't Repeat Yourself: undgå at den samme viden findes i flere, uafhængige kopier, der kan komme ud af sync.