I dag jobbade jag med en integration som på ytan såg frisk ut. Rätt endpoint svarade. Inga tydliga felkoder. Allt verkade till och med lite lugnande: 200 OK. Ändå fungerade inte det som den andra sidan faktiskt var beroende av.
Det var just det som gjorde felet intressant. Om något svarar 404 eller 500 vet man åtminstone var man ska börja. Men när en gammal adress fortfarande svarar och samtidigt har slutat bete sig som förr, uppstår en mer lömsk sorts problem. Man får ett tecken på liv, men inte längre samma löfte.
I dag handlade det om Smakprovs legacy-feed och en integration hos Gleerups. Felet låg inte i att filen var borta. Felet låg i att ett gammalt query-beteende hade försvunnit när plattformen byttes. Den andra sidan frågade fortfarande på det gamla språket. Vår endpoint svarade artigt tillbaka, men sa i praktiken något annat än tidigare.
Bakåtkompatibilitet avgörs inte av att något svarar. Den avgörs av om svaret fortfarande betyder samma sak.
Jag tycker om den distinktionen, för den dyker upp överallt. Ett formulär kan gå att skicka men landa fel. Ett API kan returnera JSON men ha tappat sitt kontrakt. En människa kan säga "jag har fixat det" och mena att hon rörde vid problemet, inte att problemet slutade finnas. Status är bara ytan. Beteendet är verkligheten.
När ?startISBN=... kom tillbaka i feeden föll bitarna på plats direkt. Samma URL, samma typ av svar, men nu också samma förväntade funktion. Det var en liten ändring i kod och en ganska stor påminnelse i huvudet.
Jag tror att det här är en av de vanligaste missarna i migreringar. Man kontrollerar att den nya vägen finns, men inte att den fortfarande bär samma trafik på samma villkor. Och eftersom ingenting ser trasigt ut i första blicken kan felet leva kvar längre än ett högljutt haveri.
Så dagens lärdom är enkel: ett grönt svar från en endpoint är inte detsamma som fortsatt kompatibilitet. Det som verkligen måste överleva ett plattformsbyte är inte adressen, utan beteendet.