Jei RESTful "PUT" operacija kažką grąžina

Man buvo įdomu, ką žmonės galvoja apie RESTful PUT operaciją, kuri atsako įstaigoje negrąžina nieko (nulio).

350
28 апр. nustatė AwkwardCoder balandžio 28 2009-04-28 16:07 '09, 16:07 2009-04-28 16:07
@ 11 atsakymų

HTTP specifikacijoje ( RFC 2616 ) yra keletas taikytinų rekomendacijų. Štai mano aiškinimas:

  • HTTP būsenos kodas 200 OK norite sėkmingai užbaigti esamo šaltinio naujinimą. Nereikalaujama atsako įstaigos. ( 9.6 , 204 No Content net tinkamesnis.)
  • HTTP 201 Created būsenos kodas sėkmingam naujo šaltinio įvykdymui, su konkrečia URI naujam ištekliui, grąžintam antraštės laukelyje „Vietovė“, ir bet kuris kitas atitinkamas URI ir išteklių metaduomenys atsispindi atsakymo įstaigoje. ( RFC 2616 10.2.2 skirsnis )
  • HTTP būsenos kodas 409 Conflict PUT, kuris nepavyko modifikuoti 3 -osios partijos, su skirtumais tarp atnaujinimo bandymo ir dabartinio išteklių atsako įstaigoje. ( RFC 2616 10.4.10 skirsnis )
  • „HTTP 400 Bad Request būsenos kodas nesėkmingam PUT, su natūralaus teksto tekstu (pavyzdžiui, anglų kalba) atsakymo įstaigoje, kuri paaiškina, kodėl PUT nepavyko. ( RFC 2616 10.4 skirsnis )
518
06 мая '09 в 0:44 2009-05-06 00:44 atsakymas pateiktas sistemoje PAUSE gegužės 06 '09, 0:44 2009-05-06 00:44

Skirtingai nei dauguma čia pateiktų atsakymų, manau, kad PUT turėtų grąžinti atnaujintą šaltinį (be HTTP kodo, žinoma).

border=0

Priežastis, kodėl norite grąžinti šaltinį kaip atsakymą į PUT operaciją, yra ta, kad kai siunčiate išteklių vaizdą į serverį, serveris taip pat gali taikyti tam tikrą apdorojimą šiam ištekliui, todėl klientas norėtų sužinoti, kaip tai atrodo sėkmingai užbaigus prašymą. (kitaip jis turės išduoti kitą GET užklausą).

126
28 апр. Atsakyti LiorH 28 balandžio. 2009-04-28 17:13 '09, 17:13 PM 2009-04-28 17:13

HTTP / 1.1 spec (9.6 skyrius) aptaria atitinkamus atsakymo / klaidų kodus. Tačiau jame neatsižvelgiama į atsakymo turinį.

Ko tikitės? Paprastas ir nedviprasmiškas man atrodo paprastas HTTP atsakymo kodas (200 ir tt).

2
28 апр. Atsakymas, kurį pateikė Brian Agnew Bal. 28 2009-04-28 16:13 '09, 16:13, 2009-04-28 16:13

Manau, kad serveris gali grąžinti turinį atsakydamas į PUT. Jei naudojate atsakymo apvalkalo formatą, leidžiantį įkelti duomenis (pvz., Formato, kurį naudoja duomenų duomenys), taip pat galite įtraukti kitus objektus, kuriuos galima keisti naudojant duomenų bazės paleidiklius ir tt (Šoniniai apkrovos duomenys aiškiai sumažina # užklausas, o tai atrodo puiki vieta optimizuoti.)

Jei aš tiesiog sutinku su PUT ir nenoriu nieko pranešti, naudoju kūno kodą 204 be kūno. Jei turiu ką pasakyti, naudoju statuso kodą 200 ir įjunkite kūną.

2
31 дек. Atsakymas pateikiamas gruodžio 31 d. 2014-12-31 13:00 '15, 13:00, 2014-12-31 13:00

„Http 201“ atsakymo kodas „Sukurta“ kartu su antrašte „Vieta“, nurodantis, kur klientas gali rasti naujai sukurtą išteklių.

1
31 июля '12 в 21:37 2012-07-31 21:37 atsakymas pateikiamas dc360 liepos 31 d. , 12:21, 2012-07-31 21:37

Savo paslaugose naudoju „RESTful API“, ir čia yra mano nuomonė: pirmiausia turime pereiti prie bendros nuomonės: PUT naudojamas atnaujinti išteklius, kurie nėra sukurti arba gauti.

Stateful resource naudodamasis: Stateless resource ir Stateful resource :

  • Neatšaukiami ištekliai Šiems ištekliams paprasčiausiai grąžinkite HttpCode tuščią kūną.

  • Apskaitos ištekliai Pavyzdžiui: išteklių versija. Šių rūšių ištekliams turite pateikti versiją, kai norite ją pakeisti, todėl grąžinti visą resursą arba grąžinti versiją klientui, todėl klientui po atnaujinimo veiksmo nereikia siųsti gavimo užklausos.

Tačiau paslaugai ar sistemai laikykite jį simple , clearly , easy to use and maintain . Tai yra svarbiausias dalykas.

1
29 марта '17 в 15:32 2017-03-29 15:32 Atsakymą pateikė „ Bluce Liu “ kovo 29 d. 17, 15:32 2017-03-29 15:32

Jei REST API serverio pusė yra reliacinė SQL duomenų bazė, tada

  1. Kiekviename įraše, kurį galima atnaujinti, turite turėti „ RowVersion “ (siekiant išvengti prarastos naujinimo problemos )
  2. Visada turėtumėte grąžinti naują įrašo kopiją po PUT (norėdami gauti naują „ RowVersion“ ).

Jei nerūpi prarastais naujinimais ar norite priversti klientus daryti GET iškart po PUT, tada nieko nepateikite iš PUT.

0
05 февр. John Henckel atsakymas 05 Feb. 2019-02-05 23:30 '19, 23.30 val. 2019-02-05 23:30

atrodo normalu ... nors aš manau, kad pagrindinis elementas sėkmės / gedimo / laiko yra išsiųstas / # baitas / ir tt būtų geriau.

redaguoti: galvojau apie duomenų vientisumo ir (arba) rašymo principus; Metaduomenys, pvz., MD5 maišymas arba gauto laiko laiko žymė, gali būti naudingi didelėms duomenų rinkmenoms.

-2
28 апр. Atsakyti į Jason S balandžio 28 d 2009-04-28 16:10 '09, 16:10, 2009-04-28 16:10

Idealiu atveju būtų grįžta į sėkmės / gedimo atsaką.

-3
28 апр. atsakymas pateikiamas 28 d. 2009-04-28 16:10 '09, 16:10, 2009-04-28 16:10

Kaip ir tuščias užklausos korpusas atitinka pradinį GET užklausos tikslą, o tuščias atsakymo korpusas atitinka pradinį PUT užklausos tikslą.

-3
28 апр. Atsakymą pateikė AnthonyWJones balandžio 28 d 2009-04-28 16:13 '09, 16:13, 2009-04-28 16:13

Yra skirtumas tarp antraštės ir HTTP atsako kūno. PUT niekada neturėtų grąžinti kūno, bet antraštėje turėtų būti grąžintas atsakymo kodas. Tiesiog pasirinkite 200, jei jis buvo sėkmingas, ir 4xx, jei ne. Nėra tokio dalyko kaip nulinio grąžinimo kodas. Kodėl norite tai padaryti?

-3
28 апр. AlexanderJohannesen atsakymas balandžio 28 d 2009-04-28 16:15 '09, 16:15 PM 2009-04-28 16:15

Kiti klausimai, susiję su etiketėmis, arba Užduoti klausimą