[Løst] Endre metoder i ett REST API

[xibriz]

Er det galt å implementere ett REST API dersom man bruker metodene på en annen måte enn de er ment å bli brukt til?

 

F.eks. så skal metodene GET "hente" informasjon og POST skal "opprette" en ny oppføring.

 

Men istedet for å følge dette, bruker man POST til å "hente" informasjon.

 

Grunnen til at man ønsker å gjøre dette er fordi man vil sende informasjon ved hver forespørsel som man ikke ønsker å legge til URL.

[Karl Skapeland]

Og hvorfor ønsker man ikke det?

[Django]

Lag en klasse som utnytter REST-apiet slik det er bygget og lag metoder som lar deg sende data på den måten du vil. Litt vanskelig å vite hvor du vil med dette dog.

 

Restful har som regel GET/PUT/PATCH.

[etse]

REST har vel som oftest: GET, PUT, POST og DELETE. Patch er ikke en del av standarden, men enkelte har kanskje kjørt sin egen vri.

Endret 27. august 2014 av etse

[Django]

Det er sant, var litt omtåket når jeg skrev dette. Det stemmer at POST, DELETE og som vi også begge glemte, OPTIONS er en del av REST. PATCH er en del av HTTP protokollen og kan derfor brukes i henhold til RFC standarden. Det er ikke lenge siden PATCH ble godkjent hos IETF.

 

HTTP RFC spesifiserer at PUT må ta en hel ressurs som inn-data. Det betyr at dersom felter ikke er spesifisert skal disse settes til NULL. Derfor faller det naturlig at man spesifiserer en metode for å oppdatere "enkle" felter, dette fordi man i tillegg ønsket å bruke mindre trafikk på å oppdatere en ressurs. Har man tunge ressurser er det lite ønskelig å sende en hel ressurs med et eller noen få felter redigert. Mange har dog implementert sin egen "PUT" som gjør det samme som "PATCH", det derimot følger ikke standarden, men er i de fleste tilfeller godtatt, mye fordi REST standarden ikke følges av mange i utgangspunktet.

 

Kilder:

http://tools.ietf.org/html/rfc5789

 

 

Hvorfor bruke PATCH?

https://www.mnot.net/blog/2012/09/05/patch

Endret 28. august 2014 av Django