POST (HTTP)

POST — კომპიუტერულ ტექნოლოგიებში HTTP პროტოკოლით მხარდაჭერილი მოთხოვნის მეთოდი, რომელიც გამოიყენება მსოფლიო აბლაბუდაში. POST-მოთხოვნა ითვალისწინებს, ვებ-სერვერის მიერ მოთხოვნის ტანით შემოსაზღვრული მონაცემების მიღებას, უმეტეს შემთხვევაში – შესანახად. ხშირად გამოიყენება ფაილის ატვირთვისას ან შევსებული ვებ-ფორმის წარსადგენად.

მის საპირისპიროდ, HTTP GET მოთხოვნის მეთოდი განკუთვნილია სერვერიდან ინფორმაციის ამოსაღებად. GET-მოთხოვნის ფარგლებში, გარკვეული მონაცემები შესაძლებელია გადაცემულ იქნას URL-მოთხოვნის სტრიქონში, მაგალითად, ძებნის პირობები, თარიღთა დიაპაზონები, ან სხვა ინფორმაცია, რომელიც განსაზღვრავს მოთხოვნას. 

POST-მოთხოვნის ფარგლებში, შესაძლებელია მოთხოვნის ტანით შემოსაზღვრული ნებისმიერი რაოდენობისა და ტიპი მონაცემი გაიგზავნოს სერვერზე. POST-მოთხოვნის სათაურის ველი, როგორც წესი, მიუთითებს შიგთავსის ტიპზე (MIME-Type).

 მონაცემთა გადაცემა 
მსოფლიო აბლაბუდა და HTTP პროტოკოლი დაფუძნებულნი არიან მოთხოვნების რიგ მეთოდებზე ან „ზმნებზე“, მათ შორისაა POST და GET, ასევე PUT, DELETE და სხვა. ვებ-ბრაუზერები ძირითადად იყენებენ მხოლოდ GET და POST მეთოდებს, თუმცა REST-სტილის ონლაინ-აპლიკაციები მრავალი სხვა მეთოდსაც იყენებენ. HTTP პროტოკოლებს შორის, POST მეთოდის მიზანია გააგზავნოს ახალი მონაცემის ობიექტის წარმოდგენა სერვერზე, იმგვარად, რომ მისი შენახვა მოხდება URI-ით იდენტიფიცირებადი რესურსის ახალი ქვერესურსის სახით. მაგალითად, URI-ისთვის http://example.com/customers, POST მოთხოვნებით შესაძლებელი იქნებოდა ახალი მომხმარებლების წარმოდგენა, რომელთაგან თითოეული მოიცავს სახელს, მისამართს, საკონტაქტო ცნობებს და სხვა. ვებგვერდების ადრინდელი დიზაინერები ამ კონცეფციას განერიდნენ ორი ძირითადი მიზეზით. პირველ რიგში, ტექნიკური თვალსაზრისით URI-ისთვის არ არის აუცილებელი ტექსტურად აღწერილი იყოს ქვემდებარე ვებ-რესურსი, რომელზეც POST-ით გადაცემული მონაცემების შენახვა მოხდება. სინამდვილეში, უფრო სავარაუდოა, რომ URI-ს ბოლო ნაწილით აღწერილი იქნება ვებ-აპლიკაციის დამუშავებადი გვერდი და მისი ტექნოლოგია, მაგალითად http://example.com/applicationform.php. მეორეც, უმეტესი ვებ-ბრაუზერის მხოლოდ POST და GET მეთოდების გამოყენების ბუნებრივი შეზღუდვების გათვალისწინებით, შემმუშავებლები გრძნობდნენ POST-მეთოდის დანიშნულების შეცვლის საჭიროებას, იმგვარად, რომ შესაძლებელი ყოფილიყო POST-ით მონაცემთა გადაცემისა და მონაცემთა მართვის მრავალი სხვა ამოცანის შესრულება, მათ შორის არსებული მონაცემების შეცვლა და მათი წაშლა.

პირველი ნაკლოვანების გამოსწორების მცდელობები გავლენიანმა პროგრამისტებმა დაიწყეს 1998 წელს. ვებ-აპლიკაციების ფრეიმოვრკები, როგორიცაა Ruby on Rails და სხვები, საშუალებას იძლევიან შემმუშავებელმა მომხმარებელი უზრუნველყოს სემანტიკურად კითხვადი URI-ით. მეორე საკითხთან დაკავშირებით, შესაძლებელია კლიენტური სკრიფტების ან დამოუკიდებელი აპლიკაციების შემუშავება, რომლებიც იყენებენ იმ HTTP მეთოდებს, რომელიც საჭიროა კერძო შემთხვევაში, თუმცა, გარე რესურსთან მუშაობისას ვებ-ფორმების უმეტესობა, რომლებიც აგზავნიან ან ცვლიან სერვერზე მონაცემებს, აღნიშნულ მეთოდებს გარდაქმნიან POST მეთოდად. 

შეუძლებელია ითქვას, რომ ყველა ვებ-ფორმამ გამხსნელ ტეგში აუცილებელია განსაზღვროს method="post". მრავალი ფორმა გამოიყენება უფრო დაზუსტებით სერვერიდან ინფორმაციის ამოსაღებად, მონაცემთა მთავარ ბაზაში ყოველგვარი ცვლილების განზრახვის გარეშე. მაგალითისთვის, საძებნი ფორმებს იდეალურად შეესაბამება method="get" განსაზღვრება.

არსებობს შემთხვევები, როდესაც HTTP GET ნაკლებად გამოსადეგია ინფორმაციის ამოსაღებადაც კი. ამის მაგალითია, როდესაც საჭიროა დიდი მოცულობის მონაცემების ჩაწერა URL-ში. ბრაუზერებსა და ვებ-სერვერებს შესაძლებელია ჰქონდეთ შეზღუდვა URL-სტრიქონის სიგრძეზე, რომლის დამუშავებას შეძლებენ ამოკვეთის ან შეცდომის გარეშე. რეზერვირებულმა სიმბოლოებმა, URL და მოთხოვნის სტრიქონებში, შესაძლებელია სტრიქონის სიგრძე მნიშვნელოვნად გაზარდონ, მაშინ, როდესაც Apache HTTP Server-ს შეუძლია 4 000 სიმბოლოსგან შემდგარი URL-ის მომსახურება,  ხოლო Microsoft Internet Explorer-ში URL-სტრიქონის მაქსიმალური სიგრძე შესაძლებელია შედგებოდეს 2 048 სიმბოლოსგან. აგრეთვე, HTTP GET არ უნდა გამოყენებულ იქნას კონფიდენციალურ ინფორმაციასთან, როგორებიცაა მომხმარებლის სახლი და პაროლი, რომლებიც აუცილებელია წარდგენილ იქნას სხვა მონაცემებთან ერთად მოთხოვნის წარმატებულად შესასრულებლად. თუნდაც თუ გამოყენებული იქნება HTTPS, რომელიც ზღუდავს ტრანზიტული მონაცემის გადაჭერის შესაძლებლობას, ბრაუზერის ისტორიასა და ვებ-სერვერის ლოგები სავარაუდოდ შეიცავენ ტექსტობრივად წარმოდგენილ სრულ URL-ს, რომელიც შესაძლებელია გამჟღავნდეს, თუ რომელიმე სისტემა გატყდება. ასეთ შემთხვევებში უნდა გამოყენებულ იქნას HTTP POST მეთოდი.

სანიმუშო პაკეტი POST მეთოდის ინფორმაციით შემდეგი სახისაა:
POST /login.jsp HTTP/1.1

Host: www.mysite.com
User-Agent: Mozilla/5.0
Content-Length: 30
Content-Type: application/x-www-form-urlencoded

login=david&password=qwerty

 ვებ-ფორმების წარდგენა 
როდესაც ბრაუზერი აგზავნის POST მოთხოვნას ვებ-ფორმის ელემენტიდან, საწყისი ინტერნეტი მედიის (MIME) ტიპი არის application/x-www-form-urlencoded. ეს არის „გასაღები-მნიშვნელობა“ წყვილების კოდირების ფორმატი გასაღებების დუბლირების შესაძლებლობით. თითოეული „გასაღები-მნიშვნელობა“ წყვილი გამოყოფილია „&“ სიმბოლოთი, ხოლო თითოეული გასაღები გამოყოფილია თავისი გასაღებისგან „=“ სიმბოლოთი. გასაღებსა და მის მნიშვნელობაში ნიშანსივრცეები ჩანაცვლდება „+“ სიმბოლოთი, შემდეგ კი ყველა არაანბანურ-ციფრული სიმბოლო ჩანაცვლდება URL-კოდირების გამოყენებით. მაგალითად, გასაღები-მნიშვნელობის ტიპის წყვილები: characters.
Name: Gareth Wylie 
Age: 24 
Formula: a + b == 13%!
კოდირდება შემდეგი სახით
Name=Gareth+Wylie&Age=24&Formula=a+%2B+b+%3D%3D+13%25%21

HTML 4.0-დან დაწყებული ფორმებს ასევე შეუძლიათ მონაცემების წარდგენა multipart/form-data ტიპად, როგორც ეს აღწერილია RFC 2388-ში (ადრეული საცდელი ვერსიისთვის, იხ. ასევე RFC 1867, რომელიც განსაზღვრული იყო HTML 2.0-ის გაფართოების სახით და ნახსენები იყო HTML 3.2-ში).

 სერვერის მდგომარეობაზე ზემოქმედება 
RFC 7231-ის მიხედვით, POST მეთოდი არ არის იდემპოტენტური, რაც ნიშნავს იმას, რომ მრავალ ერთნაირ მოთხოვნას შესაძლოა არ ჰქონდეს ისეთივე ეფექტი, როგორც მოთხოვნის ერთხელ გადაცემას. ამდენად, POST მეთოდი შესაფერისია ისეთი მოთხოვნებისათვის, რომლებიც ყოველ ჯერზე Შესრულებისას ცვლიან მდგომარეობას, მაგალითად, ბლოგის შეტყობინებაზე  კომენტირება, ან ონლაინ-გამოკითხვაში ხმის მიცემა. GET განსაზღვრულია რომ არის ნალიპოტენტური, გვერდითი მოვლენების გარეშე, ხოლო იდემპოტენტური ოპერაციები არ ახდენენ გავლენას მეორე ან სამომავლო მოთხოვნებზე.RFC 7231, 4.2.1 Safe Methods ამის გამო, ვებ-სკანერები, ისეთები როგორებიცაა საძიებო სისტემების ინდექსატორები, იყენებენ მხოლოდ GET და HEAD მეთოდებს, რათა  აღმოფხვრან საკუთარი ავტომატიზებული გამოთხოვების მიერ მსგავსი ქმედება.

თუმცა არსებობს მიზეზები, რის გამოც POST გამოიყენება იდემპოტენტური მოთხოვნების დროსაც, განსაკუთრებით ესაა როდესაც მოთხოვნა ძალიან გრძელია ან მოთხოვნაში გამოიყენება არა-ASCII სიმბოლოები. სერვერებსა და ბრაუზერებში URL-ის სიგრძე როგორც წესი შეზღუდულია, ხოლო GET მეთოდის მოთხოვნის სტრიქონი შესაძლოა აღმოჩნდეს ძალიან გრძელი, განსაკუთრებით, URL-კოდირებისას.

 სქოლიო 

კატეგორია:ინტერნეტი
კატეგორია:HTTP პროტოკოლი