მშენებლობის ვებ სერვისები REST გზა

Original web-page: http://xfront.com/REST-Web-Services.html

როჯერ ლ/Roger L. Costello

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

რა არის REST?

REST არის ტერმინი, რომელიც როი ფინგინგმა მის Ph.D. დისერტაცია [1] აღწერონ არქიტექტურის სტილი ქსელური სისტემები. REST არის აკრონიმი იდგა Representational State Transfer (წარმომადგენლობითი სახელმწიფო ტრანსფერი).

რატომ ეწოდება წარმომადგენლობითი სახელმწიფო ტრანსფერი?
ვებ არის რესურსები. რესურსი ნებისმიერი ინტერესის საგანს წარმოადგენს. მაგალითად, Boeing Aircraft Corp- ს შეუძლია განსაზღვროს 747 რესურსი. კლიენტებს შეუძლიათ გამოიყენონ რესურსი ამ URL- ით:

http://www.boeing.com/aircraft/747

რესურსის წარმომადგენლობა დაბრუნდა (ე, Boeing747.html). წარმომადგენლობა განათავსებს კლიენტის განაცხადის სახელმწიფო. შედეგი კლიენტს გადიოდა ჰიპერბმულებს Boeing747.html არის კიდევ ერთი რესურსი არის ხელმისაწვდომი. ახალი წარმომადგენლობა განათავსებს კლიენტი პროგრამა შევიდა კიდევ ერთი სახელმწიფო. ამდენად, კლიენტი პროგრამა ცვლილებები (გადაცემის) სახელმწიფოს ყოველი რესურსი წარმომადგენლობა -> წარმომადგენლობითი სახელმწიფო გადაცემა!

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

მოტივაცია REST

REST-ის მოტივაცია იყო ვებ-ის მახასიათებლების აღსაწერად, რამაც წარმატებულად შექმნა ვებ. შემდგომში ეს მახასიათებლები გამოიყენება ევოლუციის ვებ-გვერდისთვის.

REST – არქიტექტურული სტილი, არა სტანდარტული

REST არ არის სტანდარტული. ვერ დაინახავთ W3C-ს REST სპეციფიკაციას. თქვენ ვერ ვხედავ IBM ან Microsoft ან Sun გაყიდვის REST დეველოპერის ინსტრუმენტარიუმის. რატომ? იმის გამო, რომ REST მხოლოდ არქიტექტურული სტილია. თქვენ არ შეგიძლიათ ბოთლი რომ სტილი. თქვენ მხოლოდ გესმით, რომ შეიმუშავებთ თქვენს ვებ სერვისებს ამ სტილში. (კლიენტ-სერვერული არქიტექტურული სტილის ანალოგი, კლიენტ-სერვერული სტანდარტი არ არსებობს).
მიუხედავად იმისა, რომ REST არ არის სტანდარტული, ის იყენებს სტანდარტებს:

  • HTTP
  • URL
  • XML/HTML/GIF/JPEG/ა.შ. (რესურსების წარმომადგენლობა)
  • ტექსტი/xml, ტექსტი/html, გამოსახულება/gif, გამოსახულება/jpeg, და ა.შ. (MIME ტიპები)

კლასიკური REST სისტემა

ვებ არის REST სისტემა! ბევრი იმ ვებ სერვისები, რომლებიც იყენებდით ამ წლების განმავლობაში – წიგნის შეკვეთას მომსახურებაზე, საძიებო სამსახურებში, ონლაინ ლექსიკონებში და ა.შ. არის REST-ზე დაფუძნებული ვებ სერვისები. სამწუხაროდ, თქვენ იყენებთ REST-ს, REST-ის მომსახურებას და არც კი იცი.
REST შეშფოთებულია “დიდი სურათის” ვებ. იგი არ იმუშავებს განხორციელების დეტალებზე (მაგალითად, ჯავის სერვეტების ან CGI-ის გამოყენებით ვებ სერვისის განხორციელება). მოდით შევხედოთ მაგალითს შექმნას ვებ სერვისი REST “დიდი სურათი” პერსპექტივა.

ნაწილები დეპოს ვებ სერვისები
Parts Depot, Inc (ფიქტიური კომპანია) განათავსებს ზოგიერთი ვებ მომსახურება, რათა მის მომხმარებელს:

  • მიიღოს სია ნაწილები
  • დეტალური ინფორმაცია მიიღონ კონკრეტული ნაწილი
  • წარუდგინოს შესყიდვის მიზნით

მოდი განვიხილოთ, თუ როგორ ხორციელდება თითოეული ამ სერვისის განხორციელება REST მოდის.
მიიღეთ ნაწილები სიაში
ვებ-სერვისი უზრუნველყოფს მისამართების ჩამონათვალის რესურსების URL-ს. მაგალითად, კლიენტი გამოიყენებს ამ მისამართს ნაწილების სიის მისაღებად:

http://www.parts-depot.com/parts

გაითვალისწინეთ, რომ “როგორ” ვებ სერვისი წარმოშობს ნაწილები სიაში სრულიად გამჭვირვალე კლიენტს. ყველა კლიენტს იცის, რომ თუ მან/იგი წარუდგენს ზემოთ URL შემდეგ დოკუმენტი, რომელიც შეიცავს სიაში ნაწილები უბრუნდება. მას შემდეგ, რაც განხორციელება გამჭვირვალე კლიენტებს, ნაწილები Depot არის თავისუფალი, შეცვალოს ძირითადი განხორციელებას ამ რესურსის გარეშე გავლენას კლიენტებს. ეს არის  ფხვიერი დაწყვილება.

აი დოკუმენტი, რომელიც კლიენტს იღებს:

<?xml version="1.0"?>
<p:Parts xmlns:p="http://www.parts-depot.com" 
         xmlns:xlink="http://www.w3.org/1999/xlink">
      <Part id="00345" xlink:href="http://www.parts-depot.com/parts/00345"/>
      <Part id="00346" xlink:href="http://www.parts-depot.com/parts/00346"/>
      <Part id="00347" xlink:href="http://www.parts-depot.com/parts/00347"/>
      <Part id="00348" xlink:href="http://www.parts-depot.com/parts/00348"/>
</p:Parts>

[ვიფიქროთ, რომ შინაარსით მოლაპარაკებების მეშვეობით სერვისი განსაზღვრავს, რომ კლიენტს სურს, როგორც XML (მანქანათმშენებლობის დამუშავებისათვის) წარმომადგენლობა.] გაითვალისწინეთ, რომ ნაწილის სიის ბმულებს აქვს დეტალური ინფორმაციის მიღება თითოეული ნაწილის შესახებ. ეს არის REST-ის უმთავრესი ფუნქცია. კლიენტი გადასცემს ერთი სახელმწიფოდან მომდევნო დოკუმენტში ალტერნატიული მისამართების შესწავლისა და არჩევის გზით.
მიიღეთ დეტალური ნაწილი მონაცემები
ვებ-სერვისი უზრუნველყოფს URL-ს თითოეული რესურსისთვის. მაგალითად, აქ არის, თუ როგორ კლიენტს ითხოვს ნაწილი 00345:

http://www.parts-depot.com/parts/00345

აქ არის დოკუმენტი, რომელიც კლიენტს იღებს:

<?xml version="1.0"?>
<p:Part xmlns:p="http://www.parts-depot.com"   
        xmlns:xlink="http://www.w3.org/1999/xlink">
      <Part-ID>00345</Part-ID>
      <Name>Widget-A</Name>
      <Description>This part is used within the frap assembly</Description>
      <Specification xlink:href="http://www.parts-depot.com/parts/00345/specification"/>
      <UnitCost currency="USD">0.10</UnitCost>
      <Quantity>10</Quantity>
</p:Part>

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

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

რესურსი არის კონცეპტუალური ერთეული. წარმომადგენლობა არის რესურსის კონკრეტული გამოვლინება. ეს URL:

http://www.parts-depot.com/parts/00345

არის ლოგიკური URL და არა ფიზიკური URL. ამდენად, არ უნდა იყოს, მაგალითად, თითოეული ნაწილი სტატიკური HTML გვერდი. სინამდვილეში, თუ მილიონი იყო, მილიონი სტატიკური HTML გვერდები არ იქნებოდა ძალიან მიმზიდველი დიზაინი.
[შესრულების დეტალები: ნაწილების დეპოს შეუძლია განახორციელოს სერვისი, რომელიც იღებს სპეციალურ მონაცემს კონკრეტული ნაწილის შესახებ Java Servlet- ის დასაქმებით, რომელიც მასპინძლის სახელიდან სტრიქსს უთმობს, იყენებს ნაწილს რიცხვის მონაცემთა ბაზის შეკითხვას, ფორმულირება შეკითხვის შედეგებს როგორც XML, და შემდეგ გადაწერეთ XML როგორც HTTP პასუხის of გადაიხადე დატვირთვა.]
როგორც სტილი URL-ების არ უნდა გამოაშკარავდეს გამოყენებული განხორციელების ტექნიკა. კლიენტებზე გავლენის გარეშე ან შეცდომების შეცდომების გარეშე თქვენი განხორციელება უნდა იყოს თავისუფალი.
REST ვებ სერვისის მახასიათებლები

აქ არის მახასიათებლები REST:

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

REST ვებ სერვისის დიზაინის პრინციპები

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

http://www.parts-depot.com/parts/getPart?id=00345

შენიშვნა ზმნა, getPart. ნაცვლად, გამოიყენოთ არსებითი სახელი:

http://www.parts-depot.com/parts/00345

3. თქვენი რესურსების კატეგორიზაცია, იმის მიხედვით, თუ არა კლიენტებს შეუძლიათ მიიღონ რესურსის წარმომადგენლობა ან კლიენტებს შეუძლიათ შეცვალონ (დაამატოთ) რესურსი. ყოფილი, გააკეთეთ ეს რესურსები ხელმისაწვდომი HTTP GET-ის გამოყენებით. მოგვიანებით, ის რესურსები, რომლებიც ხელმისაწვდომია HTTP POST, PUT და/ან წაშლა.
4. HTTP GET-ზე ხელმისაწვდომი ყველა რესურსი უნდა იყოს გვერდითი ეფექტი უფასო. ანუ, რესურსი მხოლოდ რესურსის წარმომადგენლობაზე უნდა დაბრუნდეს. რესურსის მოხსნა არ უნდა გამოიწვიოს რესურსის შეცვლას.
5. არავინ არ არის კუნძული. ანალოგიურად, არანაირი წარმომადგენლობა არ უნდა იყოს კუნძული. სხვა სიტყვებით რომ ვთქვათ, რესურსების წარმოდგენის ფარგლებში ჰიპერბმულებს დააყენეთ კლიენტებისთვის მეტი ინფორმაციისთვის საბურღი ქვემოთ და/ან ინფორმაციის მისაღებად.
6. შეიმუშავოს მონაცემები თანდათანობით. არ გამოაქვეყნოთ ყველაფერი ერთი საპასუხო დოკუმენტით. დამატებითი ინფორმაციის მისაღებად ჰიპერბმულებს მიაწოდოს.
7. განსაზღვროს საპასუხო მონაცემების ფორმატი სქემის გამოყენებით (DTD, W3C Schema, RelaxNG, ან Schematron). იმ სერვისებისათვის, რომლებიც საჭიროებენ POST ან PUT- ს, ასევე უზრუნველყოფს სქემას საპასუხო რეაგირების ფორმატის შესახებ.
8. აღწერეთ თუ როგორ უნდა მოიწვიოს თქვენი მომსახურება WSDL დოკუმენტის გამოყენებით, ან უბრალოდ HTML დოკუმენტი.
შემაჯამებელი

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

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

ლიტერატურა

[1] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm