HTTP სტატუს კოდების სახელმძღვანელო უფასოდ

გამოიყენება Expect: 100-continue ჰედერით მოთხოვნებისთვის. სერვერი აღიარებს, რომ მზად არის სხეულის მიღებაზე, სანამ კლიენტი მას გაგზავნის. თანამედროვე ვებ აპლიკაციებში იშვიათად ჩანს.

ყველაზე ხშირად გამოიყენება WebSocket ამელიორაციებისთვის — კლიენტი მოითხოვს Upgrade: websocket და სერვერი პასუხობს 101-ით პროტოკოლის გასაცვლელად.

WebDAV შუალედური პასუხი, რომელიც გაგზავნილია კლიენტის ტაიმაუტის თავიდან აცილების მიზნით ხანგრძლივი ოპერაციების დროს. მოძველებული — თანამედროვე სერვერები არ უნდა გაგზავნოთ იგი.

საშუალებას აძლევს სერვერებს გაგზავნონ Link ჰედერი (preload/preconnect), სანამ საბოლოო პასუხი მზადდება, ასე რომ ბრაუზერებმა შეუძლიათ კრიტიკული აქტივების ამოღება უფრო სწრაფად.

სტანდარტული წარმატების პასუხი. მნიშვნელობა დამოკიდებულია HTTP მეთოდზე: GET → რესურსი დაბრუნდა, POST/PUT → ქმედება დასრულდა.

ხშირი POST-ის შემდეგ. პასუხი უნდა შეიცავდეს Location ჰედერს, რომელიც მიუთითებს ახალი რესურსის URL-ზე.

ასინქრონული ოპერაციებისთვის — სერვერი ასწროვებს სამუშაოს. კლიენტი უნდა გამოკითხოს სტატუსის ბოლო წერტილი ან მოგვიანებით უკან დაბრუნდეს.

მოთხოვნა წარმატებული იყო, მაგრამ შუამავალი (როგორიცაა კეშირების ან ტრანსფორმირების პროქსი) შეცვალა დატვირთვა სათავე სერვერიდან — მაგალითად, გამოსახულებების ხელახალი შეკუმშვა. პრაქტიკაში იშვიათი.

ხშირად გამოიყენება DELETE ოპერაციებისთვის ან PUT განახლებებისთვის, რომლებიც არ გჭირდებათ სხეულის დაბრუნება. კლიენტი არ უნდა დატოვოს მიმდინარე გვერდი.

204 მსგავსი, სხეული არ ბრუნდება — მაგრამ კლიენტი ასევე ეუბნება, რომ გადააყენოს ფორმა ან ხედი, რომელმაც გამოიწვია მოთხოვნა (მაგ. წაშალეთ ფორმის ველი შემდეგი შეყვანისთვის).

პასუხი დიაპაზონის მოთხოვნაზე. გამოიყენება ვიდეო პლეერებისა და ჩამოტვირთვის მენეჯერებისთვის შეწყვეტილი ჩამოტვირთვების აღდგენის ან დიდი ფაილების სტრიმირების შესახებ.

WebDAV: XML სხეული აჯამებს რამდენიმე ქვე-ოპერაციის შედეგს დამოუკიდებლად — მაგ. ჯამური გადატანა, სადაც ზოგი ელემენტი წარმატებული იყო და სხვა ვერ მოხერხდა.

WebDAV: გამოიყენება 207 Multi-Status პასუხში, რათა თავიდან აიცილოთ იმავე კოლექციის წევრების განმეორებით ჩამოთვლა, როდესაც ბმულები ციკლებს ქმნის.

დელტა კოდირება: სერვერი აბრუნებს განსხვავებას წინა ვერსიასთან მთელი რესურსის ნაცვლად, რითაც გაზოგადოს გამტარობა. ძალიან იშვიათად განხორციელებული.

სერვერი სთავაზობს მრავალ ვარიანტს (მაგ. სხვადსხვა ფორმატი ან ენები) და კლიენტი უნდა აირჩიოს ერთი. იშვიათად გამოიყენება, რადგან ავტომატური კონტენტის ნეგოციაცია ჩვეულებრივ ამას სახელმძღვანელოებით კეთდება.

გამოიყენეთ მუდმივი URL ცვლილებებისთვის — საძიებო სისტემები განაახლებენ თავიანთ ინდექსს. SEO ორიგინალობა გადაირთვება ახალ URL-ზე.

მიუთითებს, რომ გადამისამართება არ არის მუდმივი. კეშირება ნაკლებად აგრესიულია, ვიდრე 301. გამოიყენეთ რაც არის ის, რომ 'ავტორიზაცია საჭიროა, გადამისამართება /login-ზე'.

გამოიყენება POST წარდგენის შემდეგ — პასუხი ამბობს 'თქვენი POST მოხერხდა, იხილეთ ეს GET URL შედეგის გამო'. ბრაუზერი ყოველთვის GET-ის ახალი URL-ს.

პასუხი პირობითი მოთხოვნაზე (If-None-Match ან If-Modified-Since ჰედერთან). გაზოგადოს გამტარობა — სხეული არ ბრუნდება.

თუ ორიგინალი POST იყო, გადამისამართებაც POST-ს იყენებს. 302-ის თანამედროვე ალტერნატივაა, როცა მეთოდის შენარჩუნება მნიშვნელოვანია.

თანამედროვე ჩანაცვლება 301-ზე, როდესაც გადამისამართების შემდეგ POST მოთხოვნები POST-ის დატოვებაც გიხდება.

ჩვეულებრივი მიზეზები: მალფორმირებული JSON სხეულში, არასწორი მოთხოვნის პარამეტრი, ან აკლია აჭირებელი ველი. შეამოწმეთ მოთხოვნის სხეული და ჰედერი.

კლიენტი უნდა შეიცავდეს ავტენტიფიკაციის კრედენციალებს (ავტორიზაციის ჰედერი, კუკი, ტოკენი). 'Unauthorized' ხარვეზი — ეს ნამდვილად ნიშნავს 'არა აუთენტიფიკაციო'.

თავდაპირველად განკუთვნილი ციფრული გადახდებისთვის. თანამედროვე გამოყენება: API-მა ზოგჯერ 402-ის დაბრუნება როდესაც მომხმარებელმა გადააჭარბა თავის გადახდილ ქვოტას.

განსხვავდება 401-დან — მომხმარებელი დაკოვნილი, მაგრამ მათ ანგარიშს ამ რესურსზე უფლება არ აქვს. შეამოწმეთ როლი/უფლებების ლოგიკა.

ან URL არასწორია, ან რესურსი წაშლილია, ან ის არასოდეს არსებობდა. სერვერი ზოგჯერ დაბრუნებს 404-ს, რათა დაიმალოს, რომ 403 უფრო სწორი იქნებოდა.

მაგალითად, GET მოთხოვნა ბოლო წერტილზე, რომელიც მხოლოდ POST-ს იღებს. პასუხი უნდა შეიცავდეს Allow ჰედერს, რომელიც ჩამოთვლის ვალიდურ მეთოდებს.

კლიენტი მოითხოვა კონტენტის ტიპი, ენა ან კოდირება (Accept, Accept-Language, Accept-Encoding-ის მეშვეობით), რომელიც სერვერი ვერ აკმაყოფილებს. მრავალი სერვერი გამოტოვებს მკაცრი ნეგოციაციას და ნაგულისხმევი აბრუნებს.

401 მსგავსი, მაგრამ გამოცემული პროქსი-ს მიერ: კლიენტი უნდა გაითხოვოს Proxy-Authorization კრედენციალი. ხილული კორპორატიული ქსელებში აუთენტიფიკაციის პროქსი-ს დროს.

კლიენტს დიდი დრო დასჭირდა მოთხოვნის სხეულის გაგზავნისთვის ან კავშირი მოუსვენრად რჩებოდა. ცადეთ მოთხოვნა ხელახლა.

ჩვეულებრივ ბრუნდება ერთდროული რედაქტირების კონფლიქტებისას ან რესურსის დუბლირებისას (მაგ., მომხმარებლის შექმნა ელ. ფოსტით, რომელიც უკვე არსებობს).

უფრო ძლიერი ვიდრე 404 — სერვერი აშკარად იცის, რომ რესურსი ადრე ᲘᲧᲝ მაგრამ სამუდამოდ წაშლილი. საძიებო სისტემები მას წაშლიან ინდექსიდან.

მოთხოვნა უარყოფილი იყო, რადგან Content-Length სათაური აკლია და სერვერი უცნობი ზომის სხეულებს უარყოფს. დაამატეთ სათაური და ცადეთ ხელახლა.

დაბრუნდება როდესაც პირობითი სათაურები როგორც If-Match ან If-Unmodified-Since ვერ ხერხდებიან — ჩვეულებრივ ოპტიმისტური ჩაკეტვა: სიღმეს რესურსი შეცვალა. ხელახლა გამოთხოვეთ და ცადეთ.

გავრცელებული დიდი ფაილების აპლოდის დროს. სერვერის კონფიგურაცია (nginx, apache) ადგენს მაქს სხეულის ზომას. შეამოწმეთ სერვერის კონფიგურაცია.

ჩვეულებრივ გამოწვეულია ძალიან გრძელი მოთხოვნის სტრიქონებით (მაგ. მონაცემების GET დამაშენებელი). გადაურთეთ POST სხეულს, ან აამაღლეთ სერვერის ლიმიტი თუ მას აკონტროლებთ.

მაგალითად, application/xml გაგზავნა სერვერს, რომელიც მხოლოდ application/json მიიღებს. დააყენეთ Content-Type სათაური სწორად.

Range სათაური ითხოვს ფაილის მხარს, რომელიც არ აქვს — მაგ. ჩამოტვირთვის განახლება ფაილის ბოლოს მიღმა. პასუხი უნდა შეიცავდეს Content-Range სწორი ზომით.

გაიგზავნა როდესაც სერვერი არ მხარდაჭერს Expect: 100-continue. ზოგიერთი კლიენტი ამ სათაურს ნაგულებით აგზავნის დიდი POSTs; მისი გამორთვა ჩვეულებრივ გადაჭრის შეცდომას.

აპრილის სიცილის ხერხი 1998 წლიდან (RFC 2324). ზოგიერთი რეალური API ის იყენებს დასაცინებელსა და მოძველებული საბოლოო წერტილების მონიშვნისთვის. არა წარმოების გამოყენებისთვის.

გავრცელებული HTTP/2 კავშირის ხელახალი გამოყენებით: მოთხოვნა მივიდა სერვერთან, რომელიც არ არის კონფიგურირებული სამიზო ჰოსტის ნამეთ. კლიენტი უნდა ცადოს ახალ კავშირზე.

მაგალითად, JSON სწორად გაანალიზდა მაგრამ სავალდებულო ველი აკლია, ან ველის მნიშვნელობა დიაპაზონის გარეთ იყო. გავრცელებული REST API ვალიდაციის პასუხებში.

WebDAV: წყროს ან დანიშვულების რესურსი ჩაკეტილია სხვა კლიენტის მიერ, ოპერაცია ვერ ხერხდება. დაელოდეთ ჩაკეტვის მოხსნას ან დაწყვიტოთ იგი სწორი მარკერით.

WebDAV: დამოკიდებული ოპერაციების ჯაჭვში, უფრო ადრინდელი მოქმედება ვერ ხერხდა, ამიტომ ეს ვერ შესრულდა. ნახეთ უფრო ადრინდელი ვერცხლისფერი ფესვის მიზეზისთვის.

დაკავშირებული TLS 1.3 0-RTT (ადრეული მონაცემები): სერვერი არ რისკავს შესაძლოდ რეპლეიირებული მოთხოვნის დამუშავებას. კლიენტი უნდა ცადოს შემდეგ ხელშეკრულება სრულდება.

სერვერი უარყოფს მოთხოვნის დაემსახურებას მიმდინარე პროტოკოლით მაგრამ აკეთებს დემოგრაფიის შემდეგ — პასუხი შეიცავს Upgrade სათაურს აუცილებელი პროტოკოლის ნაცვლად.

სერვერი მოითხოვს პირობითი სათაურებს (როგორ If-Match) დაკარგული განახლებების კონფლიქტების თავიდან აცილების მიზნით. გამოთხოვეთ რესურსი, აიკოდეთ მის ETag, და აღგზავნეთ If-Match-ით.

შენელება. პასუხი უნდა შეიცავდეს Retry-After სათაურს მიუთითებს როდის ცადოთ ხელახლა. გავრცელებული API დროს, რომელსაც მოთხოვნა ქვოტები აქვს.

ან ერთი სათაური ან სულ სათაურის ზომა აჭარბებს ლიმიტს — უმეტეს შემთხვევაში გამოწვეულია გადიდებული ღია. ღია წაშალეთ ან შეამცირეთ რა თქმენთ სხეულში.

რესურსი ბლოკირებული იურიდიული მიზეზების გამო — ცენზურა, სასამართლო ბრძანებები ან რეგიონული რეგულაციები. რიცხვი მინიშნება რომანზე Fahrenheit 451.

გენერიკული უნივერსალური სერვერ მხარის შეცდომებისთვის. შეამოწმეთ სერვერის ჯურნალი რეალური მიზეზისთვის: დაუკომენტებული გამონაკლისი, მონაცემთა ბაზა შეცდომა და ა.შ.

მაგალითად, სერვერი არ აცნობს HTTP მეთოდს. იშვიათი პრაქტიკაში — უფრო ხშირად თქვენ ნახავთ 405.

გავრცელებული მიკროსერვის არქიტექტურებში. თქვენი დატვირთვის გამბილებელი ან უკან პროქსი მიიღო ცუდი პასუხი ღრმა სერვიცის გამოთხოვების დაახლოებელი.

ან ლიმიტი ან დატვირთული. პასუხი უნდა შეიცავდეს Retry-After სათაურს. ხშირად დაბრუნდება სიტყვის სიმძლავრის სიმძლავრის გაფართოების დროს.

ღრმა სერვისი არ უპასუხა საკმარის დროს. შეამოწმეთ მე-3 მხარის სერვის ჯამური და დრო მოთხოვნა კონფიგურაციის მიერ.

მოთხოვნა HTTP ვერსია ძლიერი ვერ მხარდაჭერილი სერვერის მიერ. თითქმის არასოდეს ხედი თანამედროვე კლიენტებით.

შემჭმელი კონტენტის მოლაპარაკება დასრულდა ციკლი: არჩეული ვარიანტი თავად კონფიგურირებული მოლაპარაკებისთვის. მიუთითებს სერვერის კონფიგურაციის შეცდომა.

WebDAV-კონკრეტული ხელმოწერის კვლევა მაგრამ ხანდახან ზოგადი სერვის. ნიშნავს სერვერი ვერ შეძლებს მოთხოვნის დანგრევას შენახვის შეზღუდვის გამო.

WebDAV: დამუშავება Depth: infinity მოთხოვნა შევიდა ციკლი (მაგ. წრიული ორიენტაციის). ოპერაცია სრულიად დასრულდა.

მოძველებული HTTP გაფართოებული ჩარჩოდან: სერვერი მეტი ინფორმაციის საჭიროა იმ წინ, ვიდრე მისი აღსრულება. ეფექტურად გამოსახ თანამედროვე ვებ.

გამოიყენება აკვიუმი პორტალი (სასტუმროს/აეროპორტი WiFi) მიუთითებს მომხმარებელი უნდა შევიდეს ქსელი წინ გარე საიტები დაუკავშირდება.