Ripetoj de prokura aŭtentikigo kaj ne-ripeteblaj alŝutaj korpoj
Komprenu, kial aŭtentikigaj ripetoj povas malkaŝi unufojan alŝutan fluon, kaj intence elektu limigitan bufradon aŭ ripeteblan enhavon.
GET povas aŭtentikiĝi tra prokuro dum POST aŭ PUT malsukcesas pro eraro de ne-ripetebla korpo aŭ rebobinado. La konto povas esti ĝusta: aŭtentikiga interŝanĝo povas postuli alian peton post kiam la kliento jam konsumis la alŝuton.
| Fonto de la korpo | Ripeta elekto |
|---|---|
| Malgranda finia korpo | Limigita bufro povas reteni ĝiajn bajtojn. |
| Serĉebla dosiero | La rebobina interfaco subtenata de la kliento povas igi ĝin ripetebla. |
| Generilo, tubo aŭ viva produktanto | Unufoja fonto povas postuli alian dezajnon. |
libcurl dokumentas serĉajn retrovojojn por uzoj inkluzive plurpaŝan aŭtentikigon. Jersey proponas bufritajn kaj erigitajn entity-processing reĝimojn laŭ la konduto de la konektilo. Ekzemplo de Jersey 2 Apache konektilo montras la bufritan agordon. Neniu el ili taŭgigas senlimajn alŝutojn en memoro.
Reproduktu la metodon kaj la korpan fonton, kiuj malsukcesas. Preparaj GET ne havas alŝuton por ripeti, kaj ĝi ne pruvas, ke posta alŝuto kunhavas ĝian konekton aŭ aŭtentikigan staton. Nova celo, klienta objekto aŭ konekta politiko povas ŝanĝi tion. Dosier-bazita korpo kaj viva fluo ankaŭ diferencas eĉ kiam ilia specimeno-teksto estas la sama.
Se vi bufras, difinu ĝian grandeclimon, konservan lokon kaj vivdaŭron. Samtemaj alŝutoj multobligas la koston, kaj sentemaj datumoj restas kie ajn la bufro estas tenata.
Antaŭa aŭtentikigo al konata kongrua prokuro povas eviti unu komencan defion. Ĝi ne povas ekskludi ĉiun postan aŭtentikigan raŭndon, redirektadon aŭ fermitan konekton, kiu povus postuli alian provon.
Tenu kune la prokuran respondon, la korpan konsumpunkton kaj la ripetan eraron. Poste distingigu protokolan ripeton de necerta aplika rezulto: sendo eble estis prilaborita antaŭ ol ĝia respondo perdiĝis. Sekvu la idempotencajn regulojn de la celo antaŭ ol resendi ĝin.