Noget af det første man ser i e·conomics REST-dokumentation, er:
.
PUT Overwrite / Create. PUT is always directed at a ressource. PUT to an existing ressource will overwrite the full object and must include the full entity. PUT to a non-existing ressource will depending on support of defining the ID create a ressource at that path.
.
PATCH Add / Overwrite. PATCH is always directed at a ressource. In REST terms PATCH would allow changing select properties. Please note that our API does NOT feature PATCH support on JSON documents. Please use PUT and remember this must include the full entity/document.
.
Men hvorfor i alverden understøttes PATCH dog ikke? Den kursiverede sætning er helt i overensstemmelse med standard REST-praksis, men den gør PUT rimelig ubrugelig i rigtig mange sammenhænge – deraf PATCH.
.
Den grundlæggende fordel ved PATCH er at man kan opdatere en ressource uden at have kendskab til hele API-objektet der repræsenterer den. Vi har f.eks. alle vores kunder og produkter liggende på vores egen server også, men med andre oplysninger end i e·conomic. Hvis jeg opdaterer noget på et produkt og vil synkronisere den ændring over til e·conomic kan jeg gøre det med et enkelt PATCH-kald hvortil jeg kun skal bruge ressourcens ID og egenskaben der skal opdateres. Enkelt og hurtigt.
.
Begrænset til PUT bliver jeg først nødt til at lave et GET-kald for at få objektet, afkode det fra JSON-format, opdatere den pågældende egenskab, omkode objektet til JSON igen, og så foretage et PUT-kald med den opdaterede JSON-streng. Fem trin i stedet for et.
.
Jeg står over for at skulle opdatere godt og vel 2.200 produkter på denne måde, hvilket altså lader til at komme til at kræve ikke bare 2.200, men 4.400 kald. Eller faktisk 8.800 kald, for ud over egenskaber ved selve produkterne skal jeg også opdatere currency-specific-sales-prices på dem alle sammen, hvilket ikke umiddelbart ser ud til at kunne gøres i samme kald, så der skal jeg igennem de fem trin en gang til.
.
Er der nogen logisk grund til denne mangel?