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

HTTP მოთხოვნის მეთოდები და მათი პარამეტრები

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

GET მეთოდი:

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

ითვლება, რომ ზედიზედ შესრულებული რამდენიმე იდენტური GET მოთხოვნის შედეგები უნდა იყოს იგივე.

POST მეთოდი:

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

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

GET მეთოდი უნდა იქნას გამოყენებული საინფორმაციო რესურსის შინაარსის პარამეტრების მიხედვით მოსაძიებლად, როდესაც არ არის საჭირო სამიზნე რესურსის მონაცემთა სტრუქტურებში ცვლილებების შეტანა და აზრი აქვს მოთხოვნის (URL) შენახვას სანიშნეებში. GET მეთოდი შეიძლება იყოს უფრო სწრაფი, ვიდრე მსგავსი მოთხოვნები POST მეთოდის გამოყენებით.

POST მეთოდი უნდა იქნას გამოყენებული, როდესაც თქვენ გჭირდებათ სერვერზე გადაცემული პარამეტრების დამალვა URL-დან. ეს მეთოდი ასევე უნდა იქნას გამოყენებული სამიზნე რესურსის შინაარსის ცვლილებების მოთხოვნებში, პარამეტრებში ამ ცვლილებების აღწერილობის გადაცემისას (მოთხოვნის სხეულში).

გზა რესურსისკენ?parameter1=value1¶meter2=value2&…

თუ არ გაქვთ სპეციალური HTML ფორმა პარამეტრების შევსებისთვის, მაშინ შეგიძლიათ გამართოთ თქვენი PHP აპლიკაციის ფუნქციონირება სატესტო პარამეტრების პირდაპირ ბრაუზერის ბრძანების ხაზში გადაცემით, მაგალითად:

Http://site/php-samples/sql.php?sql=select * d_staff-დან

სერვერის მხარეს მოთხოვნის პარამეტრებზე წვდომისთვის, თქვენ უნდა გამოიყენოთ გლობალური მასივები $_GETდა $_POSTშესაბამისად. თუ თქვენს აპლიკაციას არ აინტერესებს რომელი მეთოდით არის წვდომა, მაშინ უნდა გამოიყენოთ მასივი $_მოთხოვნა, რომელიც აერთიანებს $_GET და $_POST მასივების მონაცემებს, მაგალითად, შემდეგნაირად:

$sql = isset($_REQUEST["sql"]) ? $_REQUEST["sql"] : "";

ამ მაგალითში პროგრამა განსაზღვრავს, გადაეცა თუ არა „sql“ პარამეტრი: თუ კი, მის მნიშვნელობას ანიჭებს შესაბამის ცვლადს, ხოლო თუ არა, ანიჭებს მას ცარიელ მნიშვნელობას.

HTTP მოთხოვნის პარამეტრების განსაზღვრა HTML ფორმის საშუალებით

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

მეთოდი "პოსტი" მოქმედება ='sql.php' > SQL:
<b>სახელი</b> </u>="sql" cols="100" rows="8">

ფორმის ელემენტის მეთოდის ატრიბუტი განსაზღვრავს მეთოდს, რომელიც განსაზღვრავს სერვერზე მონაცემების გადაცემის მეთოდს (მიღება ან პოსტი). მოქმედების ატრიბუტი განსაზღვრავს php ფაილი , რომელიც დაამუშავებს მოთხოვნას. თუ დამმუშავებელი უნდა იყოს მიმდინარე ფაილი, მაშინ ქმედების ატრიბუტის დამატება არ არის საჭირო. ყველა ელემენტისთვის, რომლის მნიშვნელობა უნდა გადაეცეს HTTP მოთხოვნის პარამეტრად, თქვენ უნდა განსაზღვროთ უნიკალური მნიშვნელობა სახელის ატრიბუტისთვის. ეს არის ატრიბუტის მნიშვნელობა სახელიიქნება ინდექსი$_GET, $_POST ან $_REQUEST მასივებში (იხ. მაგალითი ზემოთ). ღილაკზე დაჭერა წარადგინოსაგზავნის ფორმას ყველა შეყვანილი მნიშვნელობით სერვერზე.

PHP POST მოთხოვნის შესრულების პირველი მეთოდი არის file_get_contents გამოყენება. მეორე მეთოდი გამოიყენებს fread-ს რამდენიმე სხვა ფუნქციასთან ერთად. ორივე ვარიანტი იყენებს stream_context_create ფუნქციას მოთხოვნის სათაურის საჭირო ველების შესავსებად.

კოდის ახსნა

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

როგორც file_get_contents ფუნქციაში, ასევე fread ფუნქციაში გვაქვს ორი ახალი პარამეტრი. პირველი არის use_include_path. ვინაიდან ჩვენ ვაკეთებთ HTTP მოთხოვნას, ეს იქნება ყალბი ორივე მაგალითში. როდესაც დაყენებულია true-ზე ადგილობრივი რესურსის წასაკითხად, ფუნქცია მოძებნის ფაილს include_path-ზე.

მეორე პარამეტრი არის კონტექსტი, რომელიც სავსეა stream_context_create-ის დაბრუნებული მნიშვნელობით, რომელიც იღებს $aHTTP მასივის მნიშვნელობას.

file_get_contents გამოყენება POST მოთხოვნის გასაკეთებლად

POST მოთხოვნის გასაგზავნად file_get_contents PHP-ში, თქვენ უნდა გამოიყენოთ stream_context_create, რათა ხელით შეავსოთ სათაურის ველები და მიუთითოთ რომელი “wrapper” იქნება გამოყენებული - ამ შემთხვევაში HTTP:

$sURL = "http://brugbart.com/Examples/http-post.php"; // POST URL $sPD = "name=Jacob&bench=150"; // POST მონაცემები $aHTTP = array("http" => // Wrapper, რომელიც იქნება გამოყენებული array("method" => "POST", // მოთხოვნის მეთოდი // მოთხოვნის სათაურები დაყენებულია ქვემოთ "header" => "კონტენტი - ტიპი: განაცხადი/x-www-form-urlencoded", "content" => $sPD)); $context = stream_context_create($aHTTP); $contents = file_get_contents ($sURL, false, $context); echo $შინაარსი;

Fread-ის გამოყენება POST მოთხოვნების შესასრულებლად

თქვენ შეგიძლიათ გამოიყენოთ fread ფუნქცია POST მოთხოვნის გასაკეთებლად. შემდეგი მაგალითი იყენებს stream_context_create-ს საჭირო HTTP მოთხოვნის სათაურების შესაქმნელად:

$sURL = "http://brugbart.com/Examples/http-post.php"; // POST URL $sPD = "name=Jacob&bench=150"; // POST მონაცემები $aHTTP = მასივი("http" => // შესაფუთი, რომელიც იქნება გამოყენებული array("method" => "POST", // მოთხოვნის მეთოდი // მოთხოვნის სათაურები მითითებულია ქვემოთ "header" => "შინაარსი - ტიპი: განაცხადი/x-www-form-urlencoded", "content" => $sPD)); $context = stream_context_create($aHTTP); $handle = fopen($sURL, "r", false, $context); $contents = ""; while (!feof($handle)) ( $contents .= fread($handle, 8192); ) fclose($handle); echo $შინაარსი;

GET მოთხოვნების გაკეთება PHP-ით

ახლა ჩვენ ყურადღებას გავამახვილებთ fread-ისა და file_get_contents-ის გამოყენებაზე HTTP-ისა და HTTPS-ის საშუალებით ინტერნეტიდან კონტენტის ჩამოსატვირთად. ამ სტატიაში აღწერილი მეთოდების გამოსაყენებლად, თქვენ უნდა ჩართოთ fopen wrappers ვარიანტი. ამისათვის თქვენ უნდა დააყენოთ allow_url_fopen პარამეტრი On-ზე php.ini ფაილში.

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

fread-ის გამოყენება ფაილების ინტერნეტით ჩამოსატვირთად ან მისაღებად

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

PHP POST მოთხოვნის დამუშავების შემთხვევაში, fread ფუნქციის ბოლო არგუმენტი უდრის ფრაგმენტის ზომას. ის ჩვეულებრივ არ უნდა იყოს 8192-ზე მეტი ( 8*1024 ).

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

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

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

ამიტომ, PHP-ის კონტექსტში, ამ იდეოლოგიიდან გამომდინარე, ჩვენ გავაკეთეთ შემდეგი:
1. ყოველთვის, როცა PHP-ს იწყებთ, სუპერგლობალური მასივები ($_GET, $_POST) იქმნება ნაგულისხმევად.
2. თუ შეკითხვის სტრიქონში არის კითხვის ნიშანი(?). ყოველივე ამის შემდეგ განიხილება პარამეტრები GET მოთხოვნა, ისინი წარმოდგენილია ფორმატში "key"="value" და ამპერსანდის სიმბოლო (&) გამოიყენება როგორც დელიმიტერი.
მაგალითი:
მიიღეთ /index.php?name=Andrey&surname=Galkin
ეს არის შეკითხვის სტრიქონი, არის 2 პარამეტრი. ეს პარამეტრები გადავა $_GET მასივში.
3. $_POST ივსება სხვაგვარად. ამ მასივის შიგთავსი ივსება "მოთხოვნის სათაურებიდან". ანუ მხედველობიდან აშკარად დაფარული ადგილიდან. ბრაუზერი ზრუნავს ასეთი სათაურების შექმნის ყველა საქმეზე. მიუხედავად იმისა, რომ ზოგჯერ რაღაც რედაქტირდება სათაურებში ხელით.

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

მაგალითად, გვაქვს შესვლის ფორმა 2 ველით: შესვლა და პაროლი.

წარმოვიდგინოთ, რომ ჩვენ ვიყენებთ GET მეთოდს. შემდეგ ფორმის გაგზავნისას გადავალთ შემდეგ მისამართზე /login.php?login=Andrey&password=123 დამეთანხმებით, რომ ასეთი ინფორმაციის ამ გზით გადაცემა სულაც არ არის უსაფრთხო. ნებისმიერ მსურველს შეუძლია გახსნას თქვენი ბრაუზერი და საიტის მისამართის შეყვანის დაწყების შემდეგ, ნახოს თქვენი პაროლები და შესვლა ისტორიიდან.

მაგრამ თუ ჩვენ დავაზუსტებთ POST მეთოდს, მივიღებდით შემდეგ მოთხოვნას:
POST /login.php (login=Andrey&password=123) რაც არის ფრჩხილებში დამალული იქნება და არანაირად არ შეინახება ბრაუზერში.

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

და კიდევ ერთი კარგი ამბავი ის არის, რომ ისინი შეიძლება გაერთიანდეს, მაგალითად
POST /index.php?page=login (login=Andrey&password=123) მგონი უკვე საკმარისად ავხსენი რა გამოვა და რომელი პარამეტრები რომელ მასივში შევა.

IN ბოლო დროსსულ უფრო ხშირად ვხედავ კითხვებს PHPClub-ის მთავარ ფორუმზე POST და GET მოთხოვნების შექმნის თემაზე, ასევე კითხვებს თემაზე: „როგორ შემიძლია გენერირება POST მოთხოვნა სათაურის ფუნქციის გამოყენებით“. მე მჯერა, რომ საჭიროა "i"-ების გამოყენებაში ამ ტექნოლოგიას, ვინაიდან ახალბედა პროგრამისტებს უბრალოდ არ ესმით ინტერნეტის პრინციპები, როგორც ასეთი. მაშ ასე, დავიწყოთ ჩვენი მოგზაურობა HTTP პროტოკოლის სამყაროში.

1. HTTP პროტოკოლი. შესავალი

მსურს დაუყოვნებლივ განვმარტო ერთი პატარა რამ.

საშინელი სიტყვა პროტოკოლი სხვა არაფერია, თუ არა ბევრი ადამიანის შეთანხმება, მხოლოდ ერთ მშვენიერ მომენტში ადამიანებმა გადაწყვიტეს: „მოდით ასე მოვიქცეთ და მაშინ ყველაფერი კარგად იქნება“. არაფრის შეშინება არ არის, ყველაფერი უბრალოდ აღმაშფოთებელია და ჩვენ ახლა გამოვამჟღავნებთ ამ სირცხვილს. რა არის HTTP პროტოკოლი და რისთვის გამოიყენება?

არ არსებობს სასწაულები მსოფლიოში და განსაკუთრებით პროგრამირების და ინტერნეტის სამყაროში!

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

დიახ, ძალიან მარტივია! თქვენ უბრალოდ უნდა დაისვენოთ და დაიწყოთ პროცესით სიამოვნება :-)

1.2. ჩვენი პირველი HTTP მოთხოვნის დაწერა

• თუ ფიქრობთ, რომ ყველაფერი ძალიან რთულია, მაშინ ცდებით. ადამიანი შექმნილია ისე, რომ მას უბრალოდ არ შეუძლია შექმნას რაიმე რთული, თორემ თვითონ დაიბნევა მასში :-) ასე რომ, არის ბრაუზერი და არის ვებ სერვერი.
• ბრაუზერი ყოველთვის არის მონაცემთა გაცვლის ინიციატორი. ვებ სერვერი უბრალოდ არასდროს არ გაუგზავნის რაიმეს ვინმეს ისე, რომ ბრაუზერს უგზავნის რაღაცას - ბრაუზერმა უნდა მოითხოვოს ეს.
• უმარტივესი HTTP მოთხოვნა შეიძლება ასე გამოიყურებოდეს:
• მიიღეთ http://www.php.net/ HTTP/1.0\r\n\r\n

GET (ინგლისურიდან თარგმნა ნიშნავს "მიღებას") - მოთხოვნის ტიპი შეიძლება იყოს განსხვავებული, მაგალითად POST, HEAD, PUT, DELETE (ზოგიერთ მათგანს განვიხილავთ ქვემოთ). http://www.php.net/ - URI (მისამართი), საიდანაც გვსურს მივიღოთ სულ მცირე ინფორმაცია (ბუნებრივია, იმედი გვაქვს HTML გვერდის შესწავლას). HTTP/1.0 არის პროტოკოლის ტიპი და ვერსია, რომელსაც გამოვიყენებთ სერვერთან კომუნიკაციისას.

\r\n არის სტრიქონის დასასრული, რომელიც ორჯერ უნდა განმეორდეს, რატომ გაირკვევა ცოტა მოგვიანებით.

თქვენ შეგიძლიათ შეასრულოთ ეს მოთხოვნა ძალიან მარტივად. გაუშვით telnet.exe პროგრამა, შეიყვანეთ www.php.net, როგორც ჰოსტი, მიუთითეთ პორტი 80 და უბრალოდ აკრიფეთ ეს მოთხოვნა Enter-ზე ორჯერ \r\n\r\n დაჭერით. პასუხად მიიღებთ HTML კოდს

მთავარი გვერდი საიტი www.php.net.

• 1.3 მოთხოვნის სტრუქტურამოდით შევხედოთ რისგან შედგება HTTP მოთხოვნა.

ყველაფერი საკმაოდ მარტივია. დავიწყოთ იმით, რომ HTTP მოთხოვნა სრულიად შინაარსიანი ტექსტია. რისგან შედგება ის ზოგად შემთხვევაში? ჩვენ განვიხილავთ HTTP 1.0 პროტოკოლს. ასე რომ:

• მოთხოვნა-ხაზი[გენერალი-ჰადერ | მოთხოვნა-სათაური | Entity-Header ]\r\n[ Entity-Body ]
• მოთხოვნა-ხაზი- ფარდობითი ან აბსოლუტური ბმული გვერდზე პარამეტრების ნაკრებით, მაგალითად, /index.html ან http://www.myhost.ru/index.html ან /index.html?a=1&b=qq.
• ამ უკანასკნელ შემთხვევაში, სერვერს გაეგზავნება მოთხოვნა a და b ცვლადების ნაკრებით შესაბამისი მნიშვნელობებით, ხოლო "&" ნიშანი - ამპერსანდი - ემსახურება როგორც გამყოფს პარამეტრებს შორის. HTTP-ვერსია

- HTTP პროტოკოლის ვერსია, ჩვენს შემთხვევაში "HTTP/1.0".

ჩვენ ძალიან გვაინტერესებს GET და POST დამუშავების მეთოდები. GET მეთოდით შეგიძლიათ უბრალოდ გადასცეთ პარამეტრები სკრიპტს, ხოლო POST მეთოდით შეგიძლიათ ფორმის გაგზავნის ემულაცია. GET მეთოდისთვის, Request-URI შეიძლება ასე გამოიყურებოდეს:

• "/index.html?param1=1¶m2=2".გენერალ-სათაური
  - სათაურის ძირითადი ნაწილი.
  ფორმატი:
• შეიძლება ჰქონდეს მხოლოდ ორი პარამეტრი: თარიღი ან პრაგმა. თარიღი - გრინვიჩის თარიღი ფორმატში "კვირის დღე, დღე თვე წელი HH:MM:SS GMT", მაგალითად, "Tue, 15 Nov 1994 08:12:31 GMT" - მოთხოვნის შექმნის თარიღი.პრაგმას შეიძლება ჰქონდეს ერთი ქეშის გარეშე მნიშვნელობა, რომელიც გამორთავს გვერდის ქეშირებას.

  მოთხოვნა-სათაური - სათაურის ნაწილი, რომელიც აღწერს მოთხოვნას..
  Request-Header შეიძლება ჰქონდეს შემდეგი პარამეტრები:

• დაშვება, ავტორიზაცია, From, If-Modified-Since, Referer, User-Agentამ თავში ჩვენ არ განვიხილავთ ავტორიზაციის პარამეტრს, რადგან ის გამოიყენება კერძო რესურსებზე წვდომისთვის, რაც არც ისე ხშირად არის საჭირო.
  თქვენ შეგიძლიათ გაიგოთ, თუ როგორ შექმნათ ავტორიზებული წვდომის სათაური www.w3c.org.
  დაშვება
• - ადგენს დამუშავების მისაღებ მეთოდებს. - ფორმატი: "დაშვება: GET | HEAD\n".პარამეტრი იგნორირებულია Request-Line-ში POST დამუშავების მეთოდის მითითებისას. განსაზღვრავს მოთხოვნის დამუშავების მისაღები მეთოდებს.
  პროქსი სერვერები არ ცვლის Allow პარამეტრს და ის აღწევს სერვერს უცვლელი.
  დან ელექტრონული ფოსტის მისამართივინც თხოვნა გაუგზავნა.
• ფორმატი: "From: adderss\r\n".მაგალითად, "საიდან:
  [ელფოსტა დაცულია]
  \r\n".
• თუ-შეცვლილია-მას შემდეგ- მიუთითებს, რომ მოთხოვნა არ შეცვლილა ამა თუ იმ დროიდან.
  ფორმატი: "If-Modified-Since: date\r\n"
  გამოიყენება მხოლოდ GET დამუშავების მეთოდისთვის. თარიღი მითითებულია GMT-ში იმავე ფორმატში, როგორც Date პარამეტრისთვის General-Header-ში.
• რეფერენტი- აბსოლუტური ბმული იმ გვერდზე, საიდანაც მოხდა მოთხოვნა, ანუ ბმული იმ გვერდის, საიდანაც მომხმარებელი მოვიდა ჩვენთან.
  ფორმატი: "რეფერენტი: url\n".
• მაგალითი: "რეფერენტი: www.host.ru/index.html\n".მომხმარებელი-აგენტი
  მოთხოვნის ეს ნაწილი განსაზღვრავს პარამეტრებს, რომლებიც აღწერს გვერდის ნაწილს. Entity-Header შეიძლება შეიცავდეს შემდეგ პარამეტრებს: დაშვება, Content-Encoding, Content-Length, Content-Type, ვადა იწურება, ბოლო მოდიფიცირებული, გაფართოების სათაური.
• დაშვება, ავტორიზაცია, From, If-Modified-Since, Referer, User-Agent- პარამეტრი მსგავსია Allow from General-Header.
• შიგთავსის კოდირება- მონაცემთა კოდირების ტიპი Entity-Body.
  ფორმატი: "შინაარსის კოდირება: x-gzip | x-compress | სხვა ტიპი\n".
  მაგალითი: "შინაარსის კოდირება: x-gzip\n". პერსონაჟი "|". ნიშნავს სიტყვას „ან“, ანუ ესა თუ ის ან ის და ა.შ.
  სხვა ტიპის შეიძლება მიუთითებდეს, თუ როგორ ხდება მონაცემების კოდირება, მაგალითად, POST მეთოდისთვის: "Content-Encoding: application/x-www-form-urlencoded\n".
• შინაარსი-სიგრძე- Entity-Body-ში გაგზავნილი ბაიტების რაოდენობა. Content-Length მნიშვნელობას აქვს სრულიად განსხვავებული მნიშვნელობა MIME ფორმატში გაგზავნილ მონაცემებზე, სადაც ის მოქმედებს როგორც პარამეტრი მონაცემთა ნაწილის - „გარე/ერთეული-სხეულის“ აღწერისთვის.
  სწორი რიცხვები არის მთელი რიცხვები ნულიდან და ზემოთ.
• მაგალითი: "კონტენტ-სიგრძე: 26457\n".შინაარსი-ტიპი
  - გადაცემული მონაცემების ტიპი.
• მაგალითად: "შინაარსის ტიპი: ტექსტი/html\n".იწურება
  - დრო, როდესაც გვერდი უნდა მოიხსნას ბრაუზერის ქეშიდან.
• ფორმატი: "იწურება: თარიღი\n". თარიღის ფორმატი იგივეა, რაც თარიღის ფორმატი Date პარამეტრისთვის General-Header-დან.ბოლო-მოდიფიცირებული
  - გადაცემული მონაცემების ბოლო ცვლილების დრო.
• ფორმატი: "ბოლო ცვლილება: თარიღი\n". თარიღის ფორმატი იგივეა, რაც თარიღის ფორმატი Date პარამეტრისთვის General-Header-დან.გაფართოება-სათაური
  - სათაურის ნაწილი, რომელიც შეიძლება გამიზნული იყოს, მაგალითად, ბრაუზერის ან სხვა პროგრამის მიერ დასამუშავებლად, რომელიც იღებს დოკუმენტს. ამ ნაწილში შეგიძლიათ აღწეროთ თქვენი პარამეტრები ფორმატში "ParameterName: parametervalue\n". ეს პარამეტრები იგნორირებული იქნება, თუ კლიენტის პროგრამამ არ იცის როგორ დაამუშავოს ისინი.

მაგალითად: "ქუქი: r=1\r\n" - აყენებს გვერდს კარგად ცნობილ ქუქი-ფაილებს.

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

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

2 GET მეთოდი

მოდით დავწეროთ ჩვენი მოთხოვნა.
მიიღეთ http://www.site.ru/news.html HTTP/1.0\r\n

მასპინძელი: www.site.ru\r\n
ქუქი: შემოსავალი=1\r\n

ეს მოთხოვნა გვეუბნება, რომ გვსურს მივიღოთ გვერდის შინაარსი http://www.site.ru/news.html GET მეთოდის გამოყენებით. მასპინძლის ველი მიუთითებს, რომ ეს გვერდი მდებარეობს www.site.ru სერვერზე, Referer ველი მიუთითებს, რომ ჩვენ მოვედით სიახლეების მისაღებად საიტის მთავარი გვერდიდან, ხოლო Cookie ველი მიუთითებს, რომ დაგვინიშნა ესა თუ ის ქუქი. რატომ არის ჰოსტის, რეფერერის და ქუქიების ველები ასე მნიშვნელოვანი? რადგან ნორმალური პროგრამისტები, დინამიური საიტების შექმნისას, ამოწმებენ მონაცემთა ველებს, რომლებიც ჩნდება სკრიპტებში (მათ შორის PHP) ცვლადების სახით. რისთვის არის ეს? იმისათვის, რომ, მაგალითად, არ მოხდეს საიტის გაძარცვა, ე.ი.

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

ახლა წარმოვიდგინოთ, რომ ჩვენ უნდა შეავსოთ ფორმის ველები გვერდზე და გამოგვიგზავნოთ მოთხოვნა ფორმიდან, მოდით იყოს ორი ველი ამ ფორმაში: შესვლა და პაროლი (შესვლა და პაროლი) - და, რა თქმა უნდა, ჩვენ ვიცით შესვლა. და პაროლი.
მიიღეთ http://www.site.ru/news.html HTTP/1.0\r\n
მიიღეთ http://www.site.ru/news.html?login=Petya%20Vasechkin&password=qq HTTP/1.0\r\n
მასპინძელი: www.site.ru\r\n
ქუქი: შემოსავალი=1\r\n

მითითება: http://www.site.ru/index.html\r\n ჩვენი შესვლა არის "Petya Vasechkin" რატომ უნდა დავწეროთ Petya%20Vasechkin? ეს იმიტომ ხდება, რომ სერვერმა შეიძლება ამოიცნოს სპეციალური სიმბოლოები, როგორც ახალი პარამეტრის არსებობის ან მოთხოვნის დასრულების ნიშნები და ა.შ. ამრიგად, არსებობს პარამეტრის სახელების და მათი მნიშვნელობების კოდირების ალგორითმი, რათა თავიდან იქნას აცილებული შეცდომის სიტუაციები მოთხოვნაში.სრული აღწერა

ამ ალგორითმის ნახვა შესაძლებელია და PHP-ში არის ფუნქციები rawurlencode და rawurldecode კოდირებისა და დეკოდირებისთვის, შესაბამისად. მინდა აღვნიშნო, რომ PHP თავად აკეთებს დეკოდირებას, თუ დაშიფრული პარამეტრები გადაეცემა მოთხოვნას. ამით დასრულდა ჩემი HTTP პროტოკოლის გაცნობის პირველი თავი. შემდეგ თავში განვიხილავთ სამშენებლო მოთხოვნებს, როგორიცაა POST (ინგლისურიდან ითარგმნება როგორც "გაგზავნა"), რომელიც ბევრად უფრო საინტერესო იქნება, რადგან ეს არის მოთხოვნის ტიპი, რომელიც გამოიყენება HTML ფორმებიდან მონაცემების გაგზავნისას.

3. POST მეთოდი.

3.1 კონტენტის ტიპი: განაცხადი/x-www-form-urlencoded.

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

მიიღეთ http://www.site.ru/news.html HTTP/1.0\r\n
მიიღეთ http://www.site.ru/news.html?login=Petya%20Vasechkin&password=qq HTTP/1.0\r\n
მასპინძელი: www.site.ru\r\n
კონტენტის ტიპი: განაცხადი/x-www-form-urlencoded\r\n
შინაარსი-სიგრძე: 35\r\n
ქუქი: შემოსავალი=1\r\n

აქ ჩვენ ვხედავთ Content-Type და Content-Length სათაურის ველების გამოყენების მაგალითს. Content-Length გვიჩვენებს რამდენ ბაიტს დაიკავებს მონაცემთა არე, რომელიც გამოყოფილია სათაურიდან სხვა ხაზის წყვეტით \r\n. მაგრამ პარამეტრები, რომლებიც ადრე იყო განთავსებული Request-URI-ში GET მოთხოვნისთვის, ახლა არის Entity-Body-ში. ჩანს, რომ ისინი ზუსტად ასეა ჩამოყალიბებული, უბრალოდ სათაურის შემდეგ უნდა დაწეროთ. კიდევ ერთი რამ მინდა აღვნიშნომნიშვნელოვანი წერტილი

, არაფერი უშლის ხელს Entity-Body-ში პარამეტრების სიმრავლეს პარამეტრებს Request-URI-ში სხვა სახელებით პარამეტრების განთავსებას, მაგალითად:
.....
ქუქი: შემოსავალი=1\r\n
გამოაქვეყნეთ http://www.site.ru/news.html?type=user HTTP/1.0\r\n

login=Petya%20Vasechkin&პაროლი=qq

3.2 შინაარსი-ტიპი: მრავალნაწილიანი/ფორმა-მონაცემები

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

რა არის ძირითადი განსხვავებები ამ ფორმატსა და აპლიკაციას/x-www-form-urlencoded ტიპს შორის?

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

ერთი მოთხოვნით შეგიძლიათ გადაიტანოთ სხვადასხვა ტიპის მონაცემები (როგორც ფოსტის წერილში, შეგიძლიათ ფაილების გადატანა ტექსტთან ერთად).
მიიღეთ http://www.site.ru/news.html HTTP/1.0\r\n
მიიღეთ http://www.site.ru/news.html?login=Petya%20Vasechkin&password=qq HTTP/1.0\r\n
მასპინძელი: www.site.ru\r\n

ასე რომ, დავიწყოთ. კიდევ ერთხელ განვიხილოთ იგივე მაგალითი შესვლისა და პაროლის გადაცემით, მაგრამ ახლა ახალ ფორმატში.
ქუქი: შემოსავალი=1\r\n
გამოაქვეყნეთ http://www.site.ru/news.html HTTP/1.0\r\n შიგთავსი-სიგრძე: 209\r\n
--1BEF0A57BE110FD467A შიგთავსი-სიგრძე: 209\r\n
შიგთავსი-სიგრძე: 209\r\n
\r\n შიგთავსი-სიგრძე: 209\r\n
გამოაქვეყნეთ http://www.site.ru/news.html HTTP/1.0\r\n შიგთავსი-სიგრძე: 209\r\n
შინაარსი-განლაგება: ფორმა-მონაცემები; სახელი = "შესვლა" შიგთავსი-სიგრძე: 209\r\n
შიგთავსი-სიგრძე: 209\r\n
პეტია ვასეჩკინი შიგთავსი-სიგრძე: 209\r\n
შინაარსი-განლაგება: ფორმა-მონაცემები; სახელი = "პაროლი" შიგთავსი-სიგრძე: 209\r\n

ახლა გავიგოთ რა წერია. :-) მე სპეციალურად გამოვყავი ზოგიერთი \r\n სიმბოლო თამამად, რათა არ შერწყმული იყოს მონაცემებთან. თუ დააკვირდებით, შეამჩნევთ საზღვრის ველს Content-Type-ის შემდეგ. ამ ველში მითითებულია განყოფილების გამყოფი - საზღვარი. ლათინური ასოებისა და ციფრებისგან შემდგარი სტრიქონი, ასევე ზოგიერთი სხვა სიმბოლო (სამწუხაროდ, არ მახსოვს რომელი სხვა) შეიძლება გამოყენებულ იქნას როგორც საზღვარი. მოთხოვნის ტექსტში „--“ ემატება საზღვრის დასაწყისს, მოთხოვნა კი მთავრდება საზღვრით, რომელსაც ასევე ბოლოს ემატება სიმბოლოები „--“. ჩვენს მოთხოვნას აქვს ორი სექცია, პირველი აღწერს შესვლის ველს, ხოლო მეორე აღწერს პაროლის ველს.

Content-Disposition (მონაცემთა ტიპი განყოფილებაში) ამბობს, რომ ეს იქნება მონაცემები ფორმიდან, ხოლო სახელის ველი მიუთითებს ველის სახელს. აქ მთავრდება სექციის სათაური და შემდეგ არის განყოფილების მონაცემთა არე, რომელშიც მოთავსებულია ველის მნიშვნელობა (მნიშვნელობის დაშიფვრა საჭირო არ არის!).

მინდა გავამახვილო თქვენი ყურადღება იმ ფაქტზე, რომ თქვენ არ გჭირდებათ Content-Length-ის გამოყენება განყოფილების სათაურებში, მაგრამ მოთხოვნის სათაურში უნდა გამოიყენოთ და მისი მნიშვნელობა არის მთელი Entity-Body-ის ზომა, რომელიც გამოჩნდება მეორე \ შემდეგ r\n შემდეგი შინაარსის სიგრძე: 209\ r\n. იმათ. Entity-Body გამოყოფილია სათაურიდან დამატებითი ხაზის წყვეტით (რომელიც ასევე ჩანს სექციებში).

ახლა მოდით დავწეროთ მოთხოვნა ფაილის გადაცემის შესახებ.
მიიღეთ http://www.site.ru/news.html HTTP/1.0\r\n
გამოაქვეყნეთ http://www.site.ru/postnews.html HTTP/1.0\r\n
მასპინძელი: www.site.ru\r\n
მითითება: http://www.site.ru/news.html\r\n
შინაარსი-ტიპი: მრავალნაწილიანი/ფორმა-მონაცემები; საზღვარი=1BEF0A57BE110FD467A\r\n
ქუქი: შემოსავალი=1\r\n
გამოაქვეყნეთ http://www.site.ru/news.html HTTP/1.0\r\n შიგთავსი-სიგრძე: 209\r\n
შინაარსი-სიგრძე: 491\r\n შიგთავსი-სიგრძე: 209\r\n
შიგთავსი-სიგრძე: 209\r\n
შინაარსი-განლაგება: ფორმა-მონაცემები; სახელი = "news_header" შიგთავსი-სიგრძე: 209\r\n
გამოაქვეყნეთ http://www.site.ru/news.html HTTP/1.0\r\n შიგთავსი-სიგრძე: 209\r\n
მაგალითი სიახლე შიგთავსი-სიგრძე: 209\r\n
შინაარსი-განლაგება: ფორმა-მონაცემები; სახელი = "ახალი_ფაილი"; შიგთავსი-სიგრძე: 209\r\n
filename = "news.txt" შიგთავსი-სიგრძე: 209\r\n
შიგთავსი-სიგრძე: 209\r\n
კონტენტის ტიპი: აპლიკაცია/ოქტეტი ნაკადი შიგთავსი-სიგრძე: 209\r\n
შინაარსი-განლაგება: ფორმა-მონაცემები; სახელი = "პაროლი" შიგთავსი-სიგრძე: 209\r\n

შინაარსი-გადაცემა-კოდირება: ორობითი

ძალიან მნიშვნელოვანი წერტილი. CGI სკრიპტების უმეტესობა დაწერილია ჭკვიანი ადამიანების მიერ, ამიტომ მათ მოსწონთ შემომავალი ფაილის ტიპის შემოწმება, რომელიც არის Content-Type-ში. რისთვის? ყველაზე ხშირად, ვებგვერდებზე ფაილების ატვირთვა გამოიყენება ვიზიტორისგან სურათების მისაღებად. ასე რომ, ბრაუზერი თავად ცდილობს დაადგინოს, თუ რა სახის ფაილი სურს ვიზიტორს გაგზავნოს და თხოვნაში ჩასვას შესაბამისი Content-Type. სკრიპტი ამოწმებს მას მიღებისთანავე და, მაგალითად, თუ ის არ არის gif ან jpeg, ის უგულებელყოფს ამ ფაილს. ამიტომ, მოთხოვნის „ხელით“ შექმნისას იზრუნეთ Content-Type მნიშვნელობაზე, რათა ის ყველაზე ახლოს იყოს გადაცემული ფაილის ფორმატთან.

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

4. პოსტსკრიპტი.

ვფიქრობ, რომ სერვერზე მოთხოვნის გაგზავნაზე დეტალურად საუბარი არ ღირს. ეს არის წმინდა RHP ტექნოლოგიის საკითხი :-). საკმარისია ყურადღებით წაიკითხოთ განყოფილება სოკეტებთან მუშაობის ფუნქციების ან CURL მოდულის ფუნქციების შესახებ ოფიციალურ PHP დოკუმენტაციაში.

ზემოაღნიშნულიდან გამომდინარე, იმედი მაქვს, ახლა გასაგებია, რატომ ჩნდება კითხვა: „როგორ შემიძლია გენერირება POST მოთხოვნა სათაურის ფუნქციის გამოყენებით?“ - უაზრო.

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

არის კიდევ ერთი სახის მოთხოვნა - Content-Type: multipart/mixed, იმედია ამ სტატიის წაკითხვის შემდეგ თავადაც ადვილად მიხვდებით ამ ტიპს. შეგიძლიათ დეტალურად შეისწავლოთ

ეს პოსტი არის პასუხი ჩემს ერთ-ერთ სტატიაში დასმულ კითხვაზე.

ამ სტატიაში მინდა გითხრათ რა არის HTTP მეთოდები GET/POST/PUT/DELETE და სხვა, რატომ გამოიგონეს და როგორ გამოვიყენოთ ისინი REST-ის შესაბამისად.

HTTP

მაშ, რა არის ინტერნეტის ერთ-ერთი მთავარი პროტოკოლი? პედანტებს გავაგზავნი RFC2616-ზე და დანარჩენს ადამიანურად გეტყვი :)

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

მოთხოვნისა და პასუხის საწყის ხაზებს აქვს სხვადასხვა ფორმატი - ჩვენ გვაინტერესებს მხოლოდ მოთხოვნის საწყისი ხაზი, რომელიც ასე გამოიყურება:მეთოდი URI HTTP/ ,

ვერსია სადაც METHOD არის HTTP მოთხოვნის მეთოდი, URI არის რესურსის იდენტიფიკატორი, VERSION არის პროტოკოლის ვერსია (მომენტში

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

შეტყობინების ძირითადი ნაწილი არის გადაცემული ფაქტობრივი მონაცემები. პასუხში გადაცემული მონაცემები, როგორც წესი, არის HTML გვერდი, რომელიც ბრაუზერმა მოითხოვა, ხოლო მოთხოვნაში, მაგალითად, შეტყობინების ტექსტში, გადაიცემა სერვერზე ატვირთული ფაილების შინაარსი. მაგრამ, როგორც წესი, მოთხოვნაში შეტყობინების ორგანო საერთოდ არ არის.

HTTP ურთიერთქმედების მაგალითი

მოდით შევხედოთ მაგალითს.

მოთხოვნა:
მიიღეთ /index.php HTTP/1.1 ჰოსტი: example.com მომხმარებლის აგენტი: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 მიღება: text/html კავშირი: დახურვა
პირველი ხაზი არის შეკითხვის ხაზი, დანარჩენი არის სათაურები; შეტყობინების ტექსტი აკლია

პასუხი:
HTTP/1.0 200 OK სერვერი: nginx/0.6.31 Content-Language: ru Content-Type: text/html; charset=utf-8 კონტენტი-სიგრძე: 1234 კავშირი: დახურვა ... HTML გვერდი თავად...

რესურსები და მეთოდები

დავუბრუნდეთ მოთხოვნის საწყის ხაზს და გვახსოვდეს, რომ ის შეიცავს ისეთ პარამეტრს, როგორიცაა URI. ეს ნიშნავს Uniform Resource Identifier - ერთიანი რესურსის იდენტიფიკატორი. რესურსი, როგორც წესი, არის ფაილი სერვერზე (მაგალითად, URI ამ შემთხვევაში არის „/styles.css“), მაგრამ ზოგადად რესურსი შეიძლება იყოს აბსტრაქტული ობიექტიც („/blogs/webdev/“ - წერტილები. "ვებ ბლოკის განვითარებაზე" და არა კონკრეტულ ფაილზე).

HTTP მოთხოვნის ტიპი (ასევე უწოდებენ HTTP მეთოდს) ეუბნება სერვერს, რა მოქმედების შესრულება გვინდა რესურსზე. თავდაპირველად (90-იანი წლების დასაწყისში) ვარაუდობდნენ, რომ კლიენტს შეეძლო მხოლოდ ერთი რამ სურდა რესურსისგან - მისი მიღება, მაგრამ ახლა HTTP პროტოკოლის გამოყენებით შეგიძლიათ შექმნათ პოსტები, შეცვალოთ პროფილი, წაშალოთ შეტყობინებები და მრავალი სხვა. და ეს ქმედებები ძნელია გაერთიანდეს ტერმინთან "მიღებასთან".

HTTP მეთოდების დონეზე რესურსებისგან მოქმედებების დიფერენცირების მიზნით, გამოიგონეს შემდეგი ვარიანტები:

• GET - რესურსის მიღება
• POST - რესურსის შექმნა
• PUT - რესურსის განახლება
• DELETE - რესურსის წაშლა

გთხოვთ, გაითვალისწინოთ, რომ HTTP სპეციფიკაცია არ მოითხოვს სერვერს გაიგოს ყველა მეთოდი (რომლებიდანაც რეალურად 4-ზე მეტია) - საჭიროა მხოლოდ GET და ასევე არ ეუბნება სერვერს რა უნდა გააკეთოს მან კონკრეტული მოთხოვნის მიღებისას. მეთოდი. ეს ნიშნავს, რომ სერვერი პასუხობს DELETE /index.php HTTP/1.1 მოთხოვნას არ არის ვალდებულიწაშალეთ index.php გვერდი სერვერზე, ისევე როგორც GET /index.php HTTP/1.1 მოთხოვნის შემთხვევაში არ არის ვალდებულიდაგიბრუნოთ index.php გვერდი, მას შეუძლია წაშალოს ის მაგალითად :)

REST თამაშში შედის

REST (Representational State Transfer) არის ტერმინი, რომელიც შემოიღო 2000 წელს როი ფილდინგმა, HTTP პროტოკოლის ერთ-ერთმა შემქმნელმა, როგორც ვებ აპლიკაციების შექმნის პრინციპების ჯგუფის სახელი. ზოგადად, REST მოიცავს უფრო ფართო არეალს, ვიდრე HTTP - ის ასევე შეიძლება გამოყენებულ იქნას სხვა ქსელებში სხვა პროტოკოლებით. REST აღწერს კლიენტსა და სერვერს შორის ურთიერთქმედების პრინციპებს, „რესურსისა“ და „ზმნის“ ცნებებზე დაყრდნობით (შეიძლება გავიგოთ, როგორც სუბიექტი და პრედიკატი). HTTP-ის შემთხვევაში, რესურსი იდენტიფიცირებულია მისი URI-ით, ხოლო ზმნა არის HTTP მეთოდი.

REST გვთავაზობს უარი თქვას ერთი და იგივე URI-ის გამოყენებაზე სხვადასხვა რესურსისთვის (ანუ ორი განსხვავებული სტატიის მისამართები, როგორიცაა /index.php?article_id=10 და /index.php?article_id=20 - ეს არ არის REST გზა) და სხვადასხვა მოქმედებისთვის სხვადასხვა HTTP მეთოდის გამოყენება. ანუ, REST მიდგომის გამოყენებით დაწერილი ვებ აპლიკაცია წაშლის რესურსს HTTP DELETE მეთოდით წვდომისას (რა თქმა უნდა, ეს არ ნიშნავს იმას, რომ აუცილებელია ყველაფრის და ყველას წაშლის შესაძლებლობა, მაგრამ ნებისმიერიაპლიკაციის წაშლის მოთხოვნამ უნდა გამოიყენოს HTTP DELETE მეთოდი).

REST აძლევს პროგრამისტებს შესაძლებლობას დაწერონ სტანდარტიზებული და ოდნავ უფრო ლამაზი ვებ აპლიკაციები, ვიდრე ადრე. REST-ის გამოყენებით, URI ახალი მომხმარებლის დასამატებლად არ იქნება /user.php?action=create (GET/POST მეთოდი), არამედ უბრალოდ /user.php (მკაცრად POST მეთოდი).

შედეგად, არსებული HTTP სპეციფიკაციისა და REST მიდგომის კომბინაციით, HTTP-ის სხვადასხვა მეთოდს საბოლოოდ აქვს აზრი. GET - აბრუნებს რესურსს, POST - ქმნის ახალს, PUT - განაახლებს არსებულს, DELETE - შლის მას.

პრობლემები?

დიახ, პრაქტიკაში REST-ის გამოყენებასთან დაკავშირებით მცირე პრობლემაა. ამ პრობლემას HTML ჰქვია.

PUT/DELETE მოთხოვნების გაგზავნა შესაძლებელია XMLHttpRequest-ის გამოყენებით, სერვერთან ხელით დაკავშირებით (ვთქვათ, curl ან თუნდაც telnet-ის საშუალებით), მაგრამ თქვენ არ შეგიძლიათ შექმნათ HTML ფორმა, რომელიც აგზავნის სრულფასოვან PUT/DELETE მოთხოვნას.

საქმე ის არის, რომ HTML სპეციფიკაცია არ გაძლევთ საშუალებას შექმნათ ფორმები, რომლებიც წარადგენენ მონაცემებს GET ან POST-ის გარდა. ამიტომ, სხვა მეთოდებთან ნორმალურად მუშაობისთვის, მათ ხელოვნურად უნდა მიბაძოთ. მაგალითად, Rack-ში (მექანიკა, რომლის საფუძველზეც Ruby ურთიერთქმედებს ვებ სერვერთან; Rails, Merb და სხვა Ruby Framework მზადდება Rack-ის გამოყენებით), შეგიძლიათ დაამატოთ დამალული ველი ფორმაში სახელწოდებით "_method" და მიუთითეთ მეთოდის სახელი, როგორც მნიშვნელობა (მაგ. "PUT") - ამ შემთხვევაში, POST მოთხოვნა გაიგზავნება, მაგრამ Rack-ს შეეძლება პრეტენზია წარმოაჩინოს, რომ მან მიიღო PUT და არა POST.