allan ebdrup bloghoved ny

Overvejelser omkring http PATCH

Vi implementerer et REST API det taler JSON. Vi bruger HTTP metoderne som følger:

  • POST opretter en ny ressource
  • PUT opdater en eksisternde ressource, hele ressourcen blive overskrevet med det du PUT'er
  • DELETE sletter en ressource
  • GET henter

Da vi bruger MongoDB, har det været naturligt for os at samle alle en brugers indstillinger under en URI. Der ligger efterhånden et ret stort antal indstillinger her, og for at gøre livet nemmere for vores webklient og mobile applikation, har vi brug for at kunne opdatere delmængder af disse indstillinger.

Vi kunne have valgt at tilføje en ny række URIs der rammer undergrupper af indstillingerne. Men for at vores API ikke skal drukne i en meget stor liste af URIs, har vi besluttet at tage HTTP metoden PATCH i brug.

I specifikationen for PATCH står der

A new method is necessary to improve interoperability and prevent errors. The PUT method is already defined to overwrite a resource with a complete new body, and cannot be reused to do partial changes.
The PATCH method requests that a set of changes described in the request entity be applied to the resource identified by the Request- URI. The set of changes is represented in a format called a "patch document" identified by a media type.

Dvs. du kan lave del-opdateringer af indstillingerne. Du kan ændrer en eller nogle få indstillinger og du behøver ikke at specificere den komplette liste af indstillinger, når du bare vil ændre en enkelt indstilling.

Da vores API taler JSON, faldt vi i første omgang over JSON patch specifikationen. Den foreskriver at man laver opdateringer på en lidt speciel måde:

[
     { "op": "test", "path": "/a/b/c", "value": "foo" },
     { "op": "remove", "path": "/a/b/c" },
     { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] },
     { "op": "replace", "path": "/a/b/c", "value": 42 },
     { "op": "move", "from": "/a/b/c", "path": "/a/b/d" },
     { "op": "copy", "from": "/a/b/d", "path": "/a/b/e" }
   ]

Personligt synes jeg at det virker som en noget klodset specifikation.

Vi fandt diskussionen omkring PATCH implementationen i Backbone. Vi er endt med at vælge en PATCH implementation, hvor du bare PATCH'er med den samme JSON som du ville bruge i PUT og POST. Bortset fra at du kan PATCH'e med et ikke fuldstændigt dokument. Konventionen er så, at det du PATCH'er med bliver opdateret. Hvis du sætter en attribut til null bliver den slettet, og alt du ikke specificerer bliver ikke rørt ved.

Dvs. hvis du har dokumentet

{
    a: 1,
    b: 2,
    c: 3
}

og du PATCH'er med dokumentet

{
    a: 100,
    b: null
}

vil ressourcen blive opdateret til:

{
    a: 100,
    c: 3
}

Der er faktisk en specifikation for denne slags PATCH, med media-type: application/json-merge-patch.

Jeg vil gerne høre hvad andre har af erfaringer med PATCH.

Har du selv overvejet PATCH til dit REST API? Har I valgt en anden måde at gøre det på?

Kommentarer (29)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Henrik Strøm

PATCH virker ikke i IE8 og tidligere, og hvor gerne vi allesammen end vil have at folk anvender en moderne browser, er det bare ikke altid tilfældet.

Jeg anvender django-tastypie som REST API backend. Her går det fint at sende en ufuldsændig model klasse med PUT metoden, som så blot opdaterer de felter der indgår i kaldet.

Det har den sjove effekt at man ikke kan opdatere et boolean felt repræsenteret via en checkbox i en form fra afkrydset til ikke-afkrydset, fordi ikke-afkrydsede checkboxe ikke optræder i den serialiserede form, så man må lave lidt hokus pokus for at implementere dette.

  • 0
  • 0
#4 Allan Ebdrup Blogger

PATCH virker ikke i IE8 og tidligere, og hvor gerne vi allesammen end vil have at folk anvender en moderne browser, er det bare ikke altid tilfældet.

Til IE8 og andre der ikke kan lave PATCH, har vi muligheden for at anvende connect middleware'en methodOverride.

http://www.senchalabs.org/connect/methodOverride.html

Som basalt går ud på at du kan bruge fx POST og så sætte attributten _method=PATCH eller sætte headeren x-http-method-override=PATCH, hvis du vil simulere PATCH metoden, selv om du kalder en anden metode.

  • 0
  • 0
#5 Jonas Mosbech

PATCH virker ikke i IE8 og tidligere, og hvor gerne vi allesammen end vil have at folk anvender en moderne browser, er det bare ikke altid tilfældet.

Vi bruger backbone.js til vores klient. Den implementerer et fallback for gamle IEs som virker uden server-tilpasninger. (Forudsat at brugeren ikke har slået ActiveX fra, men eftersom vores andel af IE8 brugere er forsvindende lille i forvejen, er det en risiko vi vælger at leve med.)

  • 1
  • 0
#7 Baldur Norddahl

Jeg forstår ikke denne fascination med andre HTTP metoder end GET og POST. Det eneste man får ud af det er potentielle problemer med gamle browsere og proxy servere.

Ovenover kan man læse om fall-back løsninger til POST. Kære venner, i går over åen efter vand, hvis i både skal implementere DELETE|PUT|PATCH og så en fallback POST, så kan i jo bare nøjes med POST som altid virker.

I stedet for at lege med de dårligt testede og ellers ubrugte dele af HTTP, så kan man opnå præcis det samme med en simpel HTTP header. Hvorfor skal diverse proxy'er nu opdateres med PATCH metoden, som først blev dokumenteret for få år siden? (i 2010). Hvis jeg var sysadmin og havde en tre år gammel squid kørende, så gad jeg helt sikkert ikke opgradere bare fordi i er for fine til at bruge en HTTP header i stedet for at opfinde nye HTTP metoder.

  • 3
  • 5
#8 Peter Makholm Blogger

At tro at GET, PUT, HEAD og POST er de eneste valdie HTTP metoder svare lidt til at tro at TLD'er kun kan bestå af to eller tre tegn. Man kan godt snyde sig selv, men man er selv ude om det hvis man skyder sig selv (og sine brugere) i foden.

Så med mindre man kender den server man sætter en proxy op foran, så skal man holde sig fra den slags filtrering.

  • 4
  • 0
#9 Rune Larsen

Jeg forstår ikke denne fascination med andre HTTP metoder end GET og POST. Det eneste man får ud af det er potentielle problemer med gamle browsere og proxy servere.

Hvis du selv vil definere semantikken i form af custom headere, som kun du og din server-backend forstår, så kan du jo nøjes med POST, men hvorfor så ikke bare bruge rå TCP?

IMO er det langt mere produktivt at bruge standard REST (DELETE, PUT, HEAD, GET, POST) - netop fordi proxy servere og browsere gør noget ud af, at behandle disse metoder korrekt mhp. caching mv.

Enig i, at PATCH ikke udbredes fra den ene dag til den anden, men metoden rammer et semantisk tørt sted, hvor man hidtil har været tvunget ud i skæve tolkninger af PUT og POST. Man kan dog frygte, at løbet er kørt, og at PATCH ender som endnu en måde at opdatere en del-resource vha. REST.

  • 0
  • 0
#10 Baldur Norddahl

Så med mindre man kender den server man sætter en proxy op foran, så skal man holde sig fra den slags filtrering.

Har du aldrig hørt om klient proxier? Meget almindeligt på store arbejdspladser og i mobilnetværk.

Den samme implementering håndtere domæner uanset hvor lange. Men du kan ikke generisk implementere ukendte HTTP metoder. Helt basalt så håndteres f.eks. GET og POST helt forskelligt på protokolniveau. En proxy der ikke har hørt om PATCH kan derfor ikke gøre andet end at afvise den.

PATCH er ikke med i HTTP 1.1 http://www.ietf.org/rfc/rfc2616.txt. Der defineres følgende metoder:

OPTIONS,GET,HEAD,POST,PUT,DELETE,TRACE,CONNECT

PATCH nævnes en gang med følgende passus:

"The PATCH, LINK, UNLINK methods were defined but not commonly implemented in previous versions of this specification. See RFC 2068"

En implementering af RFC 2616 kan derfor ikke forventes at have PATCH support.

Nu kommer i så og genopfinder PATCH efter at den effektivt blev afskaffet af RFC 2616 i 1999. PATCH bliver beskrevet af RFC 5789 som er dateret marts 2010.

Det har altid været en designfejl i HTTP at blande protokol sammen med semantik. HTTP metoder angiver om der skal uploades data (GET vs POST), om der skal ske noget helt andet (CONNECT), om kun headers ønskes (HEAD), om metainformation om serveren ønskes (OPTIONS).

PUT,DELETE,PATCH etc er derimod alle det samme som en af de andre, men hvor man pludselig ønsker at give semantik. Konsekvensen er at man helt unødigt er nødt til at opgradere hele infrastrukturen af proxier, klienter og webservere, for noget der reelt bare skal sendes uændret gennem systemet fra klient til web applikation. Og sådan en mekanisme har vi, det hedder http headers, så brug dog dem.

  • 2
  • 4
#11 Baldur Norddahl

Hvis du selv vil definere semantikken i form af custom headere, som kun du og din server-backend forstår, så kan du jo nøjes med POST, men hvorfor så ikke bare bruge rå TCP?

Husk at REST ikke er nogen standard. Du har i forvejen defineret en semantik efter dit eget hoved, som passer i din applikation.

Custom headere er faktisk end ikke nødvendigt. GET og POST bruger du som sædvanligt til at hente og oprette. PUT erstattes med POST, det giver sig selv at hvis du POST'er til en URI så skal indholdet erstattes. DELETE erstattes af POST med et tomt dokument. PATCH erstattes med POST af et patch dokument, genkendt enten på content-type eller på dokumentets indhold.

Forklar mig lige igen hvad i får ud af at skabe en masse problemer ved at bruge tid på at implementere alternative HTTP metoder i jeres løsning? Ekstra arbejde, ekstra problemer og ekstra arbejde med at løse disse problemer. Lose/lose/lose.

  • 0
  • 3
#12 Erik Cederstrand

Vi er endt med at vælge en PATCH implementation, hvor du bare PATCH'er med den samme JSON som du ville bruge i PUT og POST. Bortset fra at du kan PATCH'e med et ikke fuldstændigt dokument.

Ud over, at PATCH, som andre har nævnt, ikke kan forventes at virke over en bred kam, så synes jeg det er en unødvendig begrænsning, grænsende til det nævenyttige, kun at bruge PUT til komplette opdateringer. I så fald er PUT jo bare et specialtilfælde af PATCH, hvor alle felter er udfyldt. Må man så ikke bruge PATCH, hvis alle felter er udfyldt? Jeg bruger lystigt PUT til at sende både komplette og delvise objekter, og opdaterer de felter jeg modtager.

  • 4
  • 1
#13 Peter Makholm Blogger

Har du aldrig hørt om klient proxier? Meget almindeligt på store arbejdspladser og i mobilnetværk.

... film at 11.

HTTP er andet og mere end RFC2616. I øvrigt kommer httpbis til at indeholde at method registry hvor PATCH bliver grandfathered ind.

Hvis man arbejder seriøst med HTTP i dag, så er det httpbis-dokumenterne der er den bedste kilde til hvordan HTTP/1.1 skal og bør opfører sig.

Men heldigvis kan man komme uden om de fleste af den slag amatøragtige opsætninger med lidt SSL. Og folk der piller i SSL-traffik bør for alvor spankes med en brugt tepose når revolutionen kommer.

Det har altid været en designfejl i HTTP at blande protokol sammen med semantik.

En protokol er semantik! En protokol der ikke beskriver semantik er lige så brugbar som et programmeringssprog der kun består af syntax.

Derudover mener jeg dog at PATCH er den mest uinteressante udvidelse fordi den netop ikke specificerer semantiken.

  • 2
  • 0
#15 Rune Larsen

Forklar mig lige igen hvad i får ud af at skabe en masse problemer ved at bruge tid på at implementere alternative HTTP metoder i jeres løsning.

Fx er PUT og DELETE idempotente mens POST ikke er. Det er nemmere at implementere en service - især hvor den er distribueret - som understøtter metoder der på protokol-niveau er defineret til at være idempotente.

Det har altid været en designfejl i HTTP at blande protokol sammen med semantik.

HTTPs rolle er IMO netop, at være et semantisk lag ovenpå transport-laget TCP. REST/HTTP er en glimrende basis for et interface til manipulation af resurser uafhængigt af forretningsdomæne.

Når man kalder eller eksponerer en REST/HTTP grænseflade, falder behovet for dokumentation, da mennesker og værktøjer på forhånd ved hvordan metoderne bør fungere (måske pånær PATCH metoden ;-)

Enig i, at der er mange opgaver hvor REST/HTTP er uegnet. Fx hvis man ikke opererer på resurser. HTTPs ineffektivitet, dårlige multiplexing og server PUSH er løst med SPDY, som heldigvis bevarer semantikken i HTTP.

  • 3
  • 0
#16 Jørn Wildt

Jeg har gjort tilsvarende overvejelser omkring PATCH: http://soabits.blogspot.dk/2013/01/http-put-patch-or-post-partial-update...

Det eneste problem jeg er stødt på endnu er at IIS6 nærmest er umulig at sætte op til at håndtere PATCH. Men så er X-http-method-override ganske anvendelig (se f.eks. http://www.endurasoft.com/Blog/post/X-HTTP-Method-Override.aspx). Heldigvis er der ingen problemer med IIS7.

Pas på med at tildele semantik til NULL værdier: du løber meget hurtigt ind i situationer hvor du gerne vil sætte noget til NULL i stedet for at slette det ... og så er du tilbage til JSON-PATCH igen (det problem er også uddybet i min artikel).

  • 3
  • 0
#17 Allan Ebdrup Blogger

Pas på med at tildele semantik til NULL værdier: du løber meget hurtigt ind i situationer hvor du gerne vil sætte noget til NULL i stedet for at slette det ... og så er du tilbage til JSON-PATCH igen (det problem er også uddybet i min artikel).

Hvis man bruger denne specification skal man være opmærksom på at man ikke kan bruge den i tilfælde hvor man selv bruger null.

Vi har allerede en konvention hvor alle værdier der er null, undefined eller den tomme streng bliver ignoreret. Dem vil vi ikke have i vores database, og vi betragter dem på samme måde som hvis attributten ikke var sat. (vi filtrerer dem fra)

Dette var noget vi indførte fordi det gav hovedpine at forspørge data i MongoDB, når atributter kan have alle disse forskellige værdier.

Så med det på plads, er vi sikret mod den fælde du beskriver.

Og så undgår vi også den "magiske" null, der har semantik forbundet med at være sat i databasen.

  • 0
  • 0
#18 Allan Ebdrup Blogger

Forklar mig lige igen hvad i får ud af at skabe en masse problemer ved at bruge tid på at implementere alternative HTTP metoder i jeres løsning? Ekstra arbejde, ekstra problemer og ekstra arbejde med at løse disse problemer. Lose/lose/lose.

Tvært imod

  • Backbone som vi bruger i vores web-klient understøtter PATCH out-of-the-box (med support for gamle browsere, uden methodOverride som jeg skrev om).
  • Express som er vore webframework, understøtter PATCH out-of-the-box.
  • Vores json-schema'er til vores endpoints kan programmatisk tages en kopi af in-memory og modificeres programmatisk en smule, og så har vi en generisk løsning til validering af PATCH dokumenter for alle vores endpoints
  • Mapningen fra denne type PATCH til en MongoDB opdatering er på 10 linjer kode
  • Vi ignorerer i forvejen nulls (som jeg skrev om ovenfor) så det er fint at null betyder slet på PATCH

Alt i alt, er det en meget let og elegant løsning, for vores applikation. Som har været ret nem at implementere.

  • 2
  • 0
#19 Allan Ebdrup Blogger

Jeg har kun leget kort med det, men det giver ret god mening. Tidligere hare de benyttet PUT til updates, men nu er de gået over til PATCH. Du kan læse mere her: http://weblog.rubyonrails.org/2012/2/25/edge-rails-patch-is-the-new-prim...

Ja det var også det vi nåede frem til efter at have læst op på det. Ruby on rails bruger PATCH som vi har implemneteret det. Det er også sådan Backbone gør. Vi valgte at kaste os ud i det, tiden vil vise om det er en god beslutning.

Jeg har gjort tilsvarende overvejelser omkring PATCH: http://soabits.blogspot.dk/2013/01/http-put-patch-or-post-partial-update...

Godt at se Jørn, tak for link. Beroligende at høre at det rent faktisk fungerer godt for dig i praksis.

  • 1
  • 0
#20 Allan Ebdrup Blogger

Ud over, at PATCH, som andre har nævnt, ikke kan forventes at virke over en bred kam, så synes jeg det er en unødvendig begrænsning, grænsende til det nævenyttige, kun at bruge PUT til komplette opdateringer. I så fald er PUT jo bare et specialtilfælde af PATCH, hvor alle felter er udfyldt. Må man så ikke bruge PATCH, hvis alle felter er udfyldt? Jeg bruger lystigt PUT til at sende både komplette og delvise objekter, og opdaterer de felter jeg modtager.

Et quote herfra: http://stackoverflow.com/questions/2364110/whats-the-justification-behin...

PUT means what the HTTP spec defines it to mean. Clients and servers cannot change that meaning. If clients or servers use PUT in a way that contradicts its definition, at least the following thing might happen:

Put is by definition idempotent. That means a client (or intermediary!) can repeat a PUT any number of times and be sure that the effect will be the same. Suppose an intermediary receives a PUT request from a client. When it forwards the request to the server, there is a network problem. The intermediary knows by definition that it can retry the PUT until it succeeds. If the server uses PUT in a non idempotent way these potential multiple calls will have an undesired effect.

Men, jeg er ikke religøs på andres vegne, du må da gerne lave PUT med del-opdateringer hvis du vil.

Vi har valgt et forholdsvist stramt API, hvor det du POST'er eller PUT'er er præcist det der gemmes. Vi har heller ikke nogle default-værdier der indsættes hvis de ikke er specificeret og den slags.

De steder hvor vi har brug for default-værdier, autonummerering fra nummerserier og anden "magi", skal du slå den slags logik til med querystring parametre.

  • 0
  • 0
#21 Baldur Norddahl

Backbone som vi bruger i vores web-klient understøtter PATCH out-of-the-box (med support for gamle browsere, uden methodOverride som jeg skrev om).

Er der også support for nye browsere bag ved en gammel webproxy? Eksempel herpå er DIKU...

autonummerering fra nummerserier

Det er så en no go i forbindelse med PUT jævnfør dit eget citat omkring idempotens.

  • 0
  • 2
#23 Baldur Norddahl

HTTP er andet og mere end RFC2616. I øvrigt kommer httpbis til at indeholde at method registry hvor PATCH bliver grandfathered ind.

Det ser ud til at være faktuelt forkert. Citat fra httpbis dokument:

8.1.3. Registrations

The HTTP Method Registry shall be populated with the registrations below:

+---------+------+------------+---------------+ | Method | Safe | Idempotent | Reference | +---------+------+------------+---------------+ | CONNECT | no | no | Section 4.3.6 | | DELETE | no | yes | Section 4.3.5 | | GET | yes | yes | Section 4.3.1 | | HEAD | yes | yes | Section 4.3.2 | | OPTIONS | yes | yes | Section 4.3.7 | | POST | no | no | Section 4.3.3 | | PUT | no | yes | Section 4.3.4 | | TRACE | yes | yes | Section 4.3.8 | +---------+------+------------+---------------+

ingen patch... Hvilket så ser ud til at tage PATCH ud af standarten igen, efter at RFC 5789 ellers genindførte den.

Det er nu også irrelevant, om man flytter beskrivelsen fra et dokument til et andet fikser ikke det underliggende problem, nemlig at nye HTTP metoder vil være dekader om at blive implementeret i alt software der bliver brugt. Nye HTTP headere bliver derimod uden problemer overført af alt software, så derfor, tilføj din nye semantik som HTTP headere.

Det er på sin vis fint nok at definere PUT som en idempotent POST. Lad det så blive ved det og definer yderligere semantik som header felter. Tænk på det rod vi ville have, hvis man havde lavet en GET der kan caches, en GET der ikke kan caches, en GET der henter ranges og så videre.

  • 1
  • 3
#24 Peter Makholm Blogger

Det ser ud til at være faktuelt forkert. Citat fra httpbis dokument:

Nu henviste jeg også til dokumentet "Initial Hypertext Transfer Protocol (HTTP) Method Registrations" draft-ietf-httpbis-method-registrations-13:

This document registers those Hypertext Transfer Protocol (HTTP) methods which have been defined in standards-track RFCs other than draft-ietf-httpbis-p2-semantics before the IANA HTTP Method Registry was established.

Så PATCH er ikke taget ud af standarden. Det er, og har altid været, en udvidelse. At HTTP/1.1 kan udvides på denne måde har fremgået af RFC2616 afsnit 9:

The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot be assumed to share the same semantics for separately extended clients and servers.

Eller nu httpbis-p2 afsnit 4:

Additional methods, outside the scope of this specification, have been standardized for use in HTTP. All such methods ought to be registered within the HTTP Method Registry maintained by IANA, as defined in Section 8.1.

Sålænge klienten og serveren er skrevet til at kunne tale sammen, så er der ikke noget problem med nye metoder. Men det er selvfølgelig klart at en webbrowser ikke opnår ny funktionalitet bare fordi at denne funktionalitet kan beskrives som en udvidelse til HTTP. Men det forhindrer ikke andre brugere af HTTP-protokollen i at finde anvendelse for fuktionalitet som en rå webbrowser ikke kan bruge.

I Allan Ebdrupstilfælde lader det også til at resurserne der er under behandling er ret ubruglige at få fremvist i en rå webbowser. Der skal noget mere logik til at gøre dem slutbruger brugbare. Derfor er det ikke noget problem at der er visse operationer der ikke kan implementeres af en rå webbrowser uden yderligere logik.

(Ja, en javascript baseret application der kører i en browser er yderligere logik)

  • 4
  • 0
#25 Baldur Norddahl

Sålænge klienten og serveren er skrevet til at kunne tale sammen, så er der ikke noget problem med nye metoder.

En gang til overser du klient proxyer. HTTP er designet så at klient og server ikke nødvendigvis kommunikerer direkte sammen. Du har ingen kontrol med hvilke proxier der måtte være på den vej imellem klient og server. Derfor er udvidelser til HTTP i praksis en no go.

  • 0
  • 4
#26 Peter Makholm Blogger

En gang til overser du klient proxyer.

Ikke så meget "overser" som "aktivt ignorerer".

Du kan men samme argumentation påstå at HTTPS er en dårlig ide da det forhindrer brugen af tredjeparts proxyer.

Proxyer der ikke forstår HTTP/1.1 (som altså tillader denne slags udvidelser) er i sstykker. Det er der tre mulige løsninger på: Man kan fikse dem, man kan fjerne dem eller man kan omgå dem.

En mulig måde at omgå dem er ved at anvende HTTPS hvis trafikken går gennem netværk man ikke har kontrol over. Det er der også andre gode grunde til. Lokalt på et netværk er det dog nok lettest af fikse dem (hvis de har en reel funktion) eller at fjerne dem (hvis de bare er i vejen).

I vore dage bruges meget HTTP trafik i situationer hvor man kontrolerer både serveren, klienten og andre der har grund til at behandle HTTP-laget. I de scenarier giver det helt klart mening at bruge HTTP med de udvidelser der specifikt giver mening inden for ens domæne.

Dermed kan man selvfølgelig ikke gøre brug af generiske HTTP-implementationer og de features de tilbyder. Men ud over load-balancing og SSL-terminering er disse features også oftes mere til skade end til gavn for andet end statisk HTTP-trafik.

At tilføje ny funktionalitet ved hjælp af headere er på ingen måder mindre problematisk. I øjeblikket sidder jeg og kæmper med en proxy ikke understøtter Expect-headeren. Desvære implementerer den proxy netop nogle features vi har brug for.

  • 2
  • 0
#27 Morten Siebuhr

Vi har ca. PUT/GET/DELETE /prefs/username/some/key/thing, og så GET /prefs/username/, der returnerer et JSON-dokument på formen { "/some/key/ting": value, ... }.

Vi slipper for PATCH og det tog ikke lang tid at implementere i vores database (MongoDB kan vist godt til den slags forespørgsler).

  • 0
  • 0
#28 Allan Ebdrup Blogger

Vi har ca. PUT/GET/DELETE /prefs/username/some/key/thing, og så GET /prefs/username/, der returnerer et JSON-dokument på formen { "/some/key/ting": value, ... }.

Vi slipper for PATCH og det tog ikke lang tid at implementere i vores database (MongoDB kan vist godt til den slags forespørgsler).

Den variation overvejede vi også, og det kan sikkert sagtens fungere godt.

Men endte med ikke at bruge den af flere årsager. Der kan fx være argumenter omkring caching http://www.amundsen.com/blog/archives/961

Med det format ville vi heller ikke kunne genbruge vores json-schema's lige så nemt, backbone skulle twistes osv, så der er også et lille element af convenience i det.

Men det korte af det lange er nok bare, at vi bedre kan lide PATCH

Dit JSON dokument ville ikke være ret godt for os. Vi har et hierakisk dokument med under-dokumenter (Bliver til JavaScript objekter når de bliver JSON.parse'd) Så strukturen ville gå ret meget fløjten. Straigt-up almindelig JSON tak :-)

Ang. Proxyer, så kører alt vores trafik over HTTPS.

  • 0
  • 0
#29 Thomas Tanghus

Jeg er for nyligt begyndt at bruge PATCH i ownCloud Contacts[1]. Pånær et par tilfælde med ældre udgaver af lighttpd, der kunne løses med en opdatering, har der ikke været noget brok (Enterprise udgaven kører vist ikke ownCloud 6, så når IE8 brugerne kommer, får jeg måske lidt hug ;) ).

Der er dog et par brugere som får "HTTP/1.0 501 Not Implemented" tilbage selvom de hårdnakket påstår de bruger en nyere Apache2.

Kan nogen komme med andre forslag end at de må bruge en proxy eller en eller anden web server front-end som rejecter alt andet en GET, POST, PUT, DELETE?

[1] https://github.com/owncloud/contacts

  • 0
  • 0
Log ind eller Opret konto for at kommentere