RESTful proqramlaşdırma nədir?

RESTful proqramlaşdırma nədir?

3722
22 марта '09 в 17:45 2009-03-22 17:45 Hasen 22 mart 'da 17:45' də təyin olundu
@ 33 cavab
  • 1
  • 2

REST (State State State Transfer) adlı bir memarlıq üslubu , ilk olaraq nəzərdə tutulduğu kimi HTTP-dən web tətbiqlərini qoruyur. GET istəkləri istifadə edilməlidir. PUT , POSTDELETE istəkləri sırasıyla mutasiya, yaradılması və silinməsi üçün istifadə edilməlidir.

REST tərəfdarı kimi URL'leri seçim edir

 http://myserver.com/catalog/item/1729 

lakin REST arxitekturası bu "yaxşı URL'leri" tələb etmir. Parametri ilə tələb edin

 http://myserver.com/catalog?item=1729 

RESTBOX kimi hər bit.

GET tələblərinin məlumatları yeniləmək üçün heç vaxt istifadə edilməməsini unutmayın. Məsələn, səbətə bir maddə əlavə etmək üçün GET tələbi.

 http://myserver.com/addToCart?cart=314159> 

qeyri-münasib olardı. GET tələbləri idempotent olmalıdır. Yəni iki dəfə verilməsi bir dəfə verilməsi ilə fərqlənməməlidir. Bu, sorguları cacheable edir. "Səbətə əlavə et" sorğusu idempotent deyildir - onu iki dəfə sərbəst olaraq iki nüsxə səbətə əlavə edir. Bu məzmunda bir POST tələbi aydındır. Beləliklə, RESTful web proqramı POST istəklərinin bir hissəsinə ehtiyac duyur.

Mükəmməl kitabdan Core JavaServer'dan götürülüb, David M. Girinin kitabına baxır.

584
15 апр. Şirgill Fərhən Ansari tərəfindən 15 apreldə cavab verildi 2015-04-15 14:26 '15 at 2:26 PM 2015-04-15 14:26

REST - şəbəkənin əsas memarlıq prinsipi. İnternette olan inanılmaz bir şey, müştərilərin (brauzerlər) və serverlərin müştərinin əvvəlcədən server və sahib olduğu qaynaqlar barədə bilmədən mürəkkəb yollarla qarşılıqlı əlaqədə olmasıdır. Əsas məhdudiyyət, server və müştəri veb səhifəsinin HTML olması halında istifadə olunan media ilə razılaşmasıdır.

REST prinsiplərinə riayət edən bir API, müştərinin API strukturu haqqında bir şey bilməməsini tələb etmir. Əksinə, server müştərinin xidməti ilə qarşılıqlı əlaqəli məlumatı təmin etməlidir. Bunun bir nümunəsi HTML formasıdır: Server resurs və yerləşdiyi yerləri təyin edir. Brauzer əvvəlcədən məlumatı göndərməyi və əvvəlcədən göndərilən məlumatları bilməməsini bilmir. Hər iki informasiya formu tam olaraq server tərəfindən təmin edilir. (Bu prinsip HATEOAS adlanır : Hypermedia tətbiq dövlət mexanizmi kimi .)

Beləliklə, bu, HTTP ilə necə əlaqədardır və necə tətbiq oluna bilər? HTTP fiiller və resurslara yönəldilmişdir. İki verb əsasən GET və POST istifadə edir, buna görə hər kəs tanıyacaq. Bununla belə, HTTP standartı PUT və DELETE kimi digərləri müəyyən edir. Bu fe'llər daha sonra server tərəfindən verilən təlimatlara əsasən resurslara tətbiq edilir.

Məsələn, bir web xidmətinin idarə etdiyi bir istifadəçi verilənlər bazası var. Xidmətimiz xüsusi JSON-based hypermedia istifadə edir ki, bunun üçün tətbiq mimetype / json + userdb (proqram / xml + userdb və tətbiqi / nə olursa olsun + userdb - bir çox media növləri dəstəklənə bilər). Müştəri və server bu formatı anlamaq üçün proqramlaşdırılmışdı, lakin bir-biri ilə bağlı heç bir şey bilmir. Roy Fielding qeyd edir:

REST API, ehtiyatları təmsil etmək və tətbiqi vəziyyətini ifadə etmək və ya mövcud standart media növləri üçün geniş əlaqələr adlarını və / və ya hypertext markupunu müəyyən etmək üçün istifadə olunan media növü (lər) ini təsvir edən bütün təsvirlərini xərcləməlidir.

Bir əsas qayda tələbi / bu kimi bir şey qaytara bilər:

İstək

 GET / Accept: application/json+userdb 

cavab

 200 OK Content-Type: application/json+userdb { "version": "1.0", "links": [ { "href": "/user", "rel": "list", "method": "GET" }, { "href": "/user", "rel": "create", "method": "POST" } ] } 

Medyamızın təsvirindən bilirik ki, əlaqəli qaynaqlar haqqında "linklər" adlı bölmələrdən məlumat əldə edə bilərik. Buna Hypermedia Controls deyilir. Bu halda, biz bu bölmədən istifadə edə biləcəyimiz bir istifadəçi siyahısını tapa bilərik /user :

İstək

 GET /user Accept: application/json+userdb 

cavab

 200 OK Content-Type: application/json+userdb { "users": [ { "id": 1, "name": "Emil", "country: "Sweden", "links": [ { "href": "/user/1", "rel": "self", "method": "GET" }, { "href": "/user/1", "rel": "edit", "method": "PUT" }, { "href": "/user/1", "rel": "delete", "method": "DELETE" } ] }, { "id": 2, "name": "Adam", "country: "Scotland", "links": [ { "href": "/user/2", "rel": "self", "method": "GET" }, { "href": "/user/2", "rel": "edit", "method": "PUT" }, { "href": "/user/2", "rel": "delete", "method": "DELETE" } ] } ], "links": [ { "href": "/user", "rel": "create", "method": "POST" } ] } 
border=0

Bu cavabdan çox şey söyləyə bilərik. Məsələn, indi biz /user əvvəl POSTing istifadə edərək, yeni bir istifadəçi yarata biləcəyimizi bilirik:

İstək

 POST /user Accept: application/json+userdb Content-Type: application/json+userdb { "name": "Karl", "country": "Austria" } 

cavab

 201 Created Content-Type: application/json+userdb { "user": { "id": 3, "name": "Karl", "country": "Austria", "links": [ { "href": "/user/3", "rel": "self", "method": "GET" }, { "href": "/user/3", "rel": "edit", "method": "PUT" }, { "href": "/user/3", "rel": "delete", "method": "DELETE" } ] }, "links": { "href": "/user", "rel": "list", "method": "GET" } } 

Biz də mövcud məlumatları dəyişə biləcəyimizi bilirik:

İstək

 PUT /user/1 Accept: application/json+userdb Content-Type: application/json+userdb { "name": "Emil", "country": "Bhutan" } 

cavab

 200 OK Content-Type: application/json+userdb { "user": { "id": 1, "name": "Emil", "country": "Bhutan", "links": [ { "href": "/user/1", "rel": "self", "method": "GET" }, { "href": "/user/1", "rel": "edit", "method": "PUT" }, { "href": "/user/1", "rel": "delete", "method": "DELETE" } ] }, "links": { "href": "/user", "rel": "list", "method": "GET" } } 

Qeyd edək ki, bu resursları idarə etmək üçün fərqli HTTP verbs (GET, PUT, POST, DELETE, və s.) İstifadə edirik və müştəri tərəfindəki yeganə bilik mediya tərifiyəm.

Əlavə oxu:

(Bu cavab bu maddənin itkin düşdüyü üçün çox tənqiddir, əksər hissəsi isə ədalətli tənqid idi. Mən əvvəlcə təsvir etdiyim şey REST-in adətən bir neçə il əvvəl, Onun əsl mənası deyil, onu yazdıq. Məni daha yaxşı təqdim etmək üçün cavabını yenidən nəzərdən keçirdim.)

2818
22 марта '09 в 17:53 2009-03-22 17:53 cavab 22 mart 2009-cu il saat 17: 53-da Emil H tərəfindən verilmişdir

RESTful proqramlaşdırma:

  • resurslar davamlı identifikator tərəfindən müəyyən edilir: URI-lar bu günlərdə hər yerdə identifikator seçimidir.
  • HTTP metodları - bu ümumi bir vəziyyətdir - qürurlu Create , Retrieve , Update , Delete POST , GET , PUTDelete . Ancaq REST HTTP ilə məhdudlaşmır, bu, ən ümumi nəqliyyat deməkdir.
  • Resurs üçün əldə edilən faktiki nümayəndəlik, identifikatorda deyil, tələbə bağlıdır: XML, HTTP və ya hətta bir Java obyektini
  • Obamanın dövlətdə davamlılığı və dövlət təmsilçiliyi baxımından
  • resurs baxımından resurslar arasındakı əlaqələri təmsil edir: obyektlər arasındakı əlaqələr birbaşa görünüşdə yerləşdirilir
  • resurs görünüşləri görünüşün necə istifadə oluna biləcəyini və hansı hallarda onu atılmalı / ardıcıl şəkildə təkrarlamaq lazımdır: HTTP Cache-Control başlıqlarını istifadə edin

İkincisi, ehtimal ki, REST-in təsirləri və ümumi effektivliyi baxımından ən vacibdir. Ümumiyyətlə, ən mübahisəli müzakirələr brauzerdə HTTP və onun istifadəsinə diqqət yetirir və nə deyil. R. Fielding, HTTP-yə gətirib çıxaran memarlıq və həll yollarını təsvir edərkən termini hazırladığını başa düşürəm. Onun tezliyi HTTP ilə müqayisədə resursların arxitekturası və önbellek imkanları ilə daha çox maraqlanır.

RESTful architecture ilə həqiqətən maraqlanırsınızsa və niyə işləyirsə, onun tezisini bir neçə dəfə oxuyun və yalnız 5-ci fəsildə deyil, hər şeyi oxuyun! Sonra DNS-nin işə yaradığına baxın. DNS-nin hiyerarşik təşkilatı və referalların necə işlədiyini oxuyun. Sonra DNS caching'in necə işlədiyini oxuyun və nəzərdən keçirin. Nəhayət, HTTP spesifikasiyalarını oxumaq ( xüsusən RFC2616RFC3040 ) və necə və nə üçün önbellekləmə işlədiyini görür. Sonda, yalnız tıkır. Mənim üçün son vahid DNS və HTTP arasında oxşarlıqları gördükdə idi. Bundan sonra, SOA və İleti Geçiş Arayüzlerinin ölçeklendirildiğinin gerçekleşmesi tıklamaya başlayır.

Mən düşünürəm ki, memarlıq əhəmiyyətini və RESTful və Paylaşılan Nothing performansının təsirini anlamaq üçün ən əhəmiyyətli hiylə texnologiya və tətbiqin detallarını bağlamaq deyil. Onların yaradılması / saxlanmasından məsul olan resursları kimə yönəldir və s. Sonra fikirlər, protokollar və texnologiyalar haqqında düşünün.

510
22 марта '09 в 22:37 2009-03-22 22:37 Cavab 22 mart 2009- cu il saat 22.39-da D.Shawley tərəfindən verilmişdir

Burada necə görünə bilər.

Üç xüsusiyyətləri olan bir istifadəçi yaradın:

 POST /user fname=John> 

Server cavab verir:

 200 OK Location: /user/123 

Gələcəkdə istifadəçi haqqında məlumat əldə edə bilərsiniz:

 GET /user/123 

Server cavab verir:

 200 OK <fname>John</fname><lname>Doe</lname><age>25</age> 

lname dəyişdirmək üçün ( lnameage dəyişməz olaraq qalır):

 PATCH /user/123 fname=Johnny 

lname yeniləmək üçün (və, yəni, lnameage NULL olacaq):

 PUT /user/123 fname=Johnny 
398
04 июля '09 в 8:47 2009-07-04 08:47 Cavab pbreitenbach'a 04 iyul '09 'da 8:47' də verilmişdir 2009-07-04 08:47

REST REST-də praktikada mükəmməl kitab.

Nümunə Dövlət Aktarımı (REST) ​​və REST API'sını köprü mətnləri ilə oxumaq lazımdır

Martin Fowlers məqaləsi Richardson'un Yetkinlik Modelini (RMM) baxın RESTful xidmətinin nə olduğunu izah edin.

2019

174
17 окт. Cavab 17 oktuyur . 2010-10-17 00:24 '10 at 0:24 2010-10-17 00:24

REST nədir?

REST nümayəndəlik nümayəndəsinin tərcüməsi deməkdir. (Bəzən "ReST"). Bu, müştəri olmayan bir server, önbelleğe alınmış kommunikasiya protokoluna əsaslanır və HTTP-nin demək olar ki, bütün hallarda protokolu istifadə olunur.

REST şəbəkə proqramlarını tərtib etmək üçün memarlıq üslubudur. Fikir, maşınlar arasında əlaqə qurmaq üçün CORBA, RPC və ya SOAP kimi kompleks mexanizmlərdən istifadə etməklə sadə HTTP maşınlar arasında zənglər yaratmaq üçün istifadə olunur.

Bir çox hallarda, HTTP Wide World Wide Web veb səhifəsinə göz atabilirsiniz. REST əsaslı bir arxitektura kimi. RESTful applications, məlumatların dərc edilməsi (yaratmaq və / və ya yeniləmək), məlumatları oxumaq (məsələn, istəklər etmək) və məlumatları silmək üçün HTTP istəklərini istifadə edir. Beləliklə, REST bütün dörd CRUDs (Create / Read / Update / Delete) üçün HTTP istifadə edir.

REST RPC (Remote Procedural Calls) və veb xidmətləri (SOAP, WSDL, və s.) Kimi mexanizmlərə asan bir alternativdir. Daha sonra REST nə qədər asan olduğunu görəcəksiniz.

Onun sadəliyinə baxmayaraq, REST tam funksionaldır; əsasən RESTful architecture ilə icra edilə bilməz ki, web services heç bir şey edə bilərsiniz. REST "standart" deyildir. Məsələn, REST üçün heç bir W3C tövsiyəsi olmayacaqdır. REST proqramlaşdırma çərçivəsi olmasına baxmayaraq, REST ilə işləmək çox sadədir ki, Perl, Java və ya C # kimi dillərdə standart kitabxana funksiyaları ilə tez-tez "qovuşa" bilərsiniz.

Sadə, real istirahət hissi tapmaqda tapdığım ən yaxşı əlaqələrdən biri.

http://rest.elkstein.org/

131
18 нояб. Cavab 18 noyabr tarixində Ravi tərəfindən verilmişdir. 2012-11-18 23:46 '12 'də 11:46' də 2012-11-18 23:46

REST məlumatları idarə etmək üçün müxtəlif HTTP üsullarını (əsasən GET / PUT / DELETE) istifadə edir.

Bir metodu (məsələn, /user/123/delete ) aradan qaldırmaq üçün müəyyən bir URL istifadə etmək əvəzinə /user/123/delete göndərdiyiniz istifadəçi haqqında məlumat almaq üçün URL /user/[id] ünvanına DELETE sorğu göndərməlisiniz GET tələbi /user/[id]

Bunun əvəzinə, aşağıdakılardan bəzilərinə bənzər bir URL ehtiva edir.

 GET /delete_user.x?id=123 GET /user/delete GET /new_user.x GET /user/new GET /user?id=1 GET /user/id/1 

HTTP fiillerini istifadə edirsiniz ..

 GET /user/2 DELETE /user/2 PUT /user 
88
22 марта '09 в 18:20 2009-03-22 18:20 cavab 22 mart 2009 - cu il saat 18: 20-də verilir

Sisteminizin arxitekturası Roy Fielding'in təklif etdiyi REST stilinə uyğun olduğu proqramdır . Bu, interneti (daha çox və ya daha az) təsvir edən bir memarlıq üslubu olduğundan, bir çox insanlar bununla maraqlanırlar.

Bonus Cavabı: Bəli. Proqram arxitekturasını akademik və ya veb-xidmətlərin inkişaf etdiricisi kimi öyrənməsəniz, bu müddətə qulaq asmaq üçün heç bir səbəb yoxdur.

67
22 марта '09 в 17:53 2009-03-22 17:53 Cavab Hank Gay tərəfindən martın 22-də saat 17: 53-da verilir. 2009-03-22 17:53

Suala birbaşa cavab vermirəmsə, üzr istəyirik, ancaq bunları daha ətraflı nümunələrlə anlamaq daha asandır. Bütün soyuducu və terminologiyadan ötrü dərk etmək asan deyil.

Çox yaxşı bir nümunə var:

REST və Hiper mətnin izahı: Spam-E spam təmizləmə robotu

Və daha yaxşı, sadə nümunələri ilə aydın bir izahat var (PowerPoint daha mürəkkəbdir, ancaq html versiyasını ən çox əldə edə bilərsiniz):

http://www.xfront.com/REST.ppt və ya http://www.xfront.com/REST.html

Nümunələri oxuduqdan sonra mən başa düşdüm ki, Ken RESTin hypertext ilə idarə olunduğunu başa düşdüm. Doğrudur, əgər bu / user / 123 bir resursa işarə edən bir URI olduğundan həqiqətən əmin deyiləm və müştəri bu "xaricdəki" xəbəri bildiyi üçün mənə icazə verilmir.

Bu xfront sənəd REST və SOAP arasındakı fərqi izah edir və bu da çox faydalıdır. Fielding deyir, " Bu RPC, RPC səsləndirir." RPC RESTCOM deyil, belə ki, bunun üçün dəqiq səbəbləri görmək faydalıdır göstərir. (SOAP bir RPC növüdür.)

45
23 марта '09 в 20:11 2009-03-23 20:11 Cavab 23.03.2013 tarixində saat 20:11 'də tövsiyə ediləcək 2009-03-23 ​​20:11

RESTful proqramlaşdırma REST-in arxitektura üslubuna uyğun olan bina sistemləri (API) ilə bağlı olduğunu söyləyərdim.

Mən bu fantastik, qısa və anlamaq asan REST tutorial dan Dr. M. Elkstein və çoxu üçün sualınıza cavab verəcək əhəmiyyətli bir hissəyə istinadən:

RESTi öyrənin: Tutorial

REST şəbəkə proqramlarını tərtib etmək üçün memarlıq üslubudur. Fikir, maşınlar arasında əlaqə qurmaq üçün CORBA, RPC və ya SOAP kimi kompleks mexanizmlərdən istifadə etməklə sadə HTTP maşınlar arasında zənglər yaratmaq üçün istifadə olunur.

  • Bir çox cəhətdən, HTTP-based World Wide Web özü REST-əsaslı bir arxitektura kimi qəbul edilə bilər.

RESTful tətbiqlər məlumatların dərc edilməsi (yaratmaq və / və ya yeniləmək), məlumatları oxumaq (məsələn, istəklər yaratmaq) və məlumatları silmək üçün HTTP istəklərini istifadə edir. Beləliklə, REST bütün dörd CRUD əməliyyatları (Create / Read / Update / Delete) üçün HTTP istifadə edir.

Mən səni axmaq hiss etməyim lazım olduğunu düşünmürəm, çünki Yığın daşması xaricində REST haqqında eşitməmisiniz ... Mən də eyni vəziyyətdə olardım! Bu sualın cavabını SO cavablandırır. Niyə REST böyük hiss edirsə, indi bəzi duyğularını rahatlaşdırmaq olar.

44
12 июля '13 в 19:33 2013-07-12 19:33 Cavab yalnız Sizə verilir 12 iyul '13 'də saat 7:33' də 2013-07-12 19:33

REST nədir?

REST, rəsmi sözlərlə REST, mövcud fundamental "Veb" prinsiplərini istifadə edərək müəyyən prinsiplərə əsaslanan bir memarlıq üslubudur. REST xidmətlərini yaratmaq üçün istifadə olunan 5 əsas şəbəkə əsasları vardır.

  • Prinsip 1: hər şey bir qayda var REST-in memarlıq üslubunda məlumatlar və funksiyalar resurslar hesab edilir və bir qayda olaraq İnternetdə ünsiyyət resurslarının identifikatorlarını (URI) istifadə etmək mümkündür.
  • Prinsip 2: Hər bir resurs unikal identifikator (URI) tərəfindən müəyyən edilir.
  • Prinsip 3: sadə və vahid interfeyslərdən istifadə edin.
  • Prinsip 4: Rabitə təqdim edir
  • Prinsip 5: Sivil olun
37
25 июля '13 в 12:05 2013-07-25 12:05 cavab 25 iyul 2013-cü il saat 12:05 tarixində Suresh Gupta tərəfindən verilmişdir 2013-07-25 12:05

İstifadəçi 123 ilə əlaqədar "/ user / 123" qaynağında RESTful olduğunu söyləyən bir çox cavab görürəm.

Termini hazırlayan Roy Fielding, REST API'sinin hipertext əsaslı olması lazım olduğunu söylədi . Xüsusilə, "REST API sabit qaynaq adları və ya hiyerarşiləri müəyyən etməməlidir".

Beləliklə, əgər "/ user / 123" yolunuz müvəqqəti olaraq kodlaşdırılıbsa, bu, həqiqətən, RESTful deyil. HTTP-nin yaxşı istifadəsi bəlkə deyil. Amma REST. Hipermətdən gəlmək lazımdır.

34
22 марта '09 в 19:36 2009-03-22 19:36 Cavab 22 mart 2009-cu il saat 19: 36-da Ken tərəfindən verilmişdir

Cavab çox sadədir, Roy Fielding yazdığı bir dissertasiya var.] Bu dissertasiyada REST prinsiplərini müəyyənləşdirir. Tətbiq bütün bu prinsiplərə əməl edərsə, bu REST tətbiqidir.

RESTful termini yaradılıb, çünki ppl REST sözünü REST kimi qeyri-REST tətbiqini REST olaraq çağırdı. Bundan sonra RESTful termini də tükəndi. Hal-hazırda deyilən REST tətbiqlərinin əksəriyyəti vahid interfeys məhdudiyyətinin HATEOAS hissəsinə uyğun gəlmədiyindən API API və Hypermedia API-ləri haqqında danışırıq .

REST məhdudiyyətləri aşağıdakılardır:

  • müştəri-server arxitekturası

    Beləliklə, məsələn, PUB / SUB sockets işləmir, REQ / REP əsaslanır.

  • vətəndaşlığı olmayan əlaqələr

    Beləliklə, server müştərinin statusunu saxlamır. Bu, üçüncü tərəf sessiyalarını saxlaya bilmək üçün serverdan istifadə edə bilməyəcəyini və hər bir tələbi təsdiqləməlisiniz. Müştəriləriniz şifrəli bir əlaqə vasitəsilə əsas auth başlıqlarını göndərə bilər. (Böyük ərizələrdə bir çox sessiyanın davam etdirilməsi çətindir.)

  • mümkünsə önbelleği istifadə edin

    Buna görə də eyni tələbləri bir daha yerinə yetirməyə ehtiyac yoxdur.

  • müştəri ilə server arasındakı ümumi müqavilə kimi vahid interfeys

    Müştəri ilə server arasındakı müqavilə server tərəfindən dəstəklənmir. Başqa sözlə, müştəri xidmətin həyata keçirilməsindən ayrılmalıdır. Вы можете достичь этого состояния, используя стандартные решения, такие как стандарт IRI (URI) для идентификации ресурсов, стандарт HTTP для обмена сообщениями, стандартные типы MIME для описания формата сериализации тела, метаданные (возможно, словари RDF, микроформаты и т.д.) До описывают семантику различных частей тела сообщения. Чтобы отделить структуру IRI от клиента, вы должны отправлять гиперссылки клиентам в форматах гипермедиа, таких как (HTML, JSON-LD, HAL и т.д.). Таким образом, клиент может использовать метаданные (возможно, отношения ссылок, словари RDF), назначенные гиперссылкам, для навигации по конечному автомату приложения через соответствующие переходы состояния для достижения своей текущей цели.

    Например, когда клиент хочет отправить заказ в интернет-магазин, он должен проверить гиперссылки в ответах, отправленных веб-магазином. Проверяя ссылки, они обнаруживают один, описанный с http://schema.org/OrderAction . Клиент знает словаря schema.org, поэтому он понимает, что, активировав эту гиперссылку, он отправит заказ. Таким образом, он активирует гиперссылку и отправляет сообщение POST https://example.com/api/v1/order с правильным телом. После этого служба обрабатывает сообщение и отвечает результатом с соответствующим заголовком HTTP-заголовка, например 201 - created по успеху. Чтобы комментировать сообщения с подробными метаданными, стандартное решение использовать формат RDF, например JSON-LD с помощью словарного кода REST, например Hydra и такие слова, как schema.org или любые другие связанный data vocab и, возможно, специальный пользовательский словарь, если необходимо. Теперь это непросто, поэтому большинство ppl используют HAL и другие простые форматы, которые обычно предоставляют только ВОЕННЫЙ ВОЕН, но не поддерживают связанные данные.

  • создать многоуровневую систему для повышения масштабируемости

    Система REST состоит из иерархических слоев. Каждый слой содержит компоненты, которые используют сервисы компонентов, которые находятся на следующем ниже уровне. Таким образом, вы можете легко добавлять новые слои и компоненты.

    Например, есть клиентский уровень, который содержит клиентов и ниже, что есть уровень сервиса, который содержит одну услугу. Теперь вы можете добавить кэш клиентской стороны между ними. После этого вы можете добавить еще один экземпляр службы и балансировщик нагрузки и т.д. Код клиента и код службы не будут меняться.

  • код по требованию для расширения клиентских функций

    Это ограничение необязательно. Например, вы можете отправить парсер для определенного типа носителя для клиента и т.д. Для этого вам может понадобиться стандартная система загрузчика плагинов на клиенте, или ваш клиент будет связан с решением загрузчика плагинов.

Ограничения REST приводят к масштабируемой системе, в которой клиенты отделены от реализаций сервисов. Таким образом, клиенты могут быть повторно использованы, как и браузеры в Интернете. Клиенты и службы имеют одни и те же стандарты и словари, поэтому они могут понимать друг друга, несмотря на то, что клиент не знает детали реализации службы. Это позволяет создавать автоматизированные клиенты, которые могут находить и использовать сервисы REST для достижения своих целей. В долгосрочной перспективе эти клиенты могут общаться друг с другом и доверять друг другу задачами, как это делают люди. Если мы добавим шаблоны обучения таким клиентам, то результатом будет один или несколько ИИ, использующих сеть машин, а не один серверный парк. Итак, в конце мечта о Бернерсе Ли: семантическая паутина и искусственный интеллект станут реальностью. Так что в 2030 году мы заканчиваем Скайнет. До тех пор...; -)

26
ответ дан inf3rno 23 нояб. '13 в 1:49 2013-11-23 01:49

RESTful (Репрезентативная передача состояний) API-программирование - это написание веб-приложений на любом языке программирования, используя 5 базовых программ архитектурный стиль :

  • Ресурс (данные, информация).
  • Уникальный глобальный идентификатор (все ресурсы уникальны с помощью URI ).
  • Равномерный интерфейс - используйте простой и стандартный интерфейс (HTTP).
  • Представление - вся связь осуществляется посредством представления (например, XML / JSON )
  • Stateless (каждый запрос выполняется в полной изоляции, проще кэшировать и балансировать нагрузку),

Другими словами, вы пишете простые сетевые приложения "точка-точка" по HTTP, которые используют такие глаголы, как GET, POST, PUT или DELETE, реализуя архитектуру RESTful, которая предлагает стандартизацию интерфейса, который предоставляет каждый "ресурс". Это не что иное, как использование текущих функций Интернета простым и эффективным способом (очень успешная, проверенная и распределенная архитектура). Это альтернатива более сложным механизмам, таким как SOAP , CORBA и RPC .

Программирование RESTful соответствует дизайну веб-архитектуры и, если оно правильно реализовано, позволяет вам в полной мере использовать масштабируемую веб-инфраструктуру.

20
ответ дан kenorb 15 июня '14 в 22:02 2014-06-15 22:02

Если бы мне пришлось сократить оригинальную диссертацию по REST до 3 коротких предложений, я думаю, что следующее отражает ее суть:

  • Ресурсы запрашиваются через URL-адреса.
  • Протоколы ограничены тем, что вы можете связывать с помощью URL-адресов.
  • Метаданные передаются как пары имя-значение (данные для сообщений и параметры строки запроса).

После этого легко впасть в дискуссии об адаптации, соглашениях о кодировании и лучших практиках.

Интересно, что в диссертации нет упоминаний о HTTP POST, GET, DELETE или PUT. Это, должно быть, кто-то позже интерпретирует "наилучшую практику" для "единого интерфейса".

Когда дело доходит до веб-сервисов, нам кажется, что нам нужно каким-то образом отличить архитектуры WSDL и SOAP, которые добавляют значительные сложности и, возможно, намного ненужную сложность интерфейса. Они также требуют дополнительных рамок и инструментов разработчика для реализации. Я не уверен, что REST - лучший термин для разграничения интерфейсов с общим интерфейсом и чрезмерно инженерных интерфейсов, таких как WSDL и SOAP. Но нам что-то нужно.

17
ответ дан Nathan Andelin 01 февр. '12 в 20:23 2012-02-01 20:23

REST - это архитектурный образец и стиль написания распределенных приложений. Это не стиль программирования в узком смысле.

Говоря, что вы используете стиль REST, похоже на то, что вы построили дом в определенном стиле: например, Tudor или Victorian. И REST как стиль программного обеспечения, и Tudor или Victorian как домашний стиль могут быть определены качествами и ограничениями, которые их создают. Например, REST должен иметь разделение клиентского сервера, где сообщения самоописаны. В домах Тюдорского стиля есть перекрывающиеся фронтоны и крыши, которые круто разбиты передними фронтонами. Вы можете прочитать диссертацию Роя, чтобы узнать больше об ограничениях и качествах, составляющих REST.

REST, в отличие от домашних стилей, нелегко было последовательно и практически применялось. Возможно, это было намеренно. Оставляя свою фактическую реализацию до дизайнера. Таким образом, вы свободны делать то, что хотите, до тех пор, пока вы удовлетворите ограничениям, изложенным в диссертации, которые вы создаете системы REST.

Bonus:

Вся сеть основана на REST (или REST была основана на Интернете). Поэтому, как веб-разработчик, вам может понадобиться знать об этом, хотя нет необходимости писать хорошие веб-приложения.

17
ответ дан suing 02 февр. '12 в 0:20 2012-02-02 00:20

Вот мой основной план REST. Я попытался продемонстрировать мышление за каждым компонентом архитектуры RESTful, чтобы понимание концепции было более интуитивным. Надеюсь, это поможет демистифицировать REST для некоторых людей!

REST (Репрезентативный перенос состояний) - это архитектура проектирования, в которой описывается, как спроектированы и решены сетевые ресурсы (то есть узлы, которые обмениваются информацией). В общем, архитектура RESTful делает это так, чтобы клиент (запрашивающая машина) и сервер (машина ответа) могли запрашивать чтение, запись и обновление данных без необходимости знать, как сервер работает и сервер может пройти он обратно, не нужно ничего знать о клиенте. Хорошо, круто... но как мы это делаем на практике?

  • Наиболее очевидным требованием является наличие какого-либо универсального языка, чтобы сервер мог сообщить клиенту, что он пытается сделать с запросом, и для ответа сервера.

  • Но чтобы найти какой-либо данный ресурс, а затем сообщить клиенту, где живет этот ресурс, должен быть универсальный способ указывать на ресурсы. В это место входят универсальные идентификаторы ресурсов (URI); они в основном уникальные адреса для поиска ресурсов.

Но архитектура REST не заканчивается! Хотя приведенное выше отвечает основным потребностям того, что мы хотим, мы также хотим иметь архитектуру, которая поддерживает большой объемный трафик, поскольку любой сервер обычно обрабатывает ответы от нескольких клиентов. Таким образом, мы не хотим перегружать сервер, помня информацию о предыдущих запросах.

  • Поэтому мы накладываем ограничение на то, что каждая пара запросов и @ между клиентом и сервером является независимой, что означает, что сервер не должен ничего помнить о предыдущих запросах (предыдущие состояния взаимодействия клиент-сервер) с ответьте на новый запрос. Это означает, что мы хотим, чтобы наши взаимодействия были апатридами.

  • Чтобы еще больше снизить нагрузку на наш сервер из повторных вычислений, которые уже были недавно выполнены для данного клиента, REST также позволяет кэшировать. В основном, кэширование означает получение моментального снимка исходного ответа, предоставленного клиенту. Если клиент повторяет тот же запрос, сервер может предоставить клиенту снимок, а не повторить все вычисления, необходимые для создания начального ответа. Однако, поскольку это моментальный снимок, если моментальный снимок не истек - сервер заранее задает время истечения срока действия - и ответ был обновлен с момента первоначального кеша (т.е. Запрос дал бы другой ответ, чем кешированный ответ), клиент не будет видеть обновления до истечения срока действия кэша (или очистка кэша), и ответ снова будет показан с нуля.

  • Последнее, что вы часто здесь обсуждаете в архитектуре RESTful, это то, что они многоуровневы. Фактически мы уже обсуждали это требование неявно в нашем обсуждении взаимодействия между клиентом и сервером. В основном это означает, что каждый слой в нашей системе взаимодействует только с соседними слоями. Поэтому в нашем обсуждении клиентский уровень взаимодействует с нашим уровнем сервера (и наоборот), но могут быть и другие уровни сервера, которые помогают процессу первичного сервера запрашивать, с которым клиент напрямую не взаимодействует. Скорее, сервер передает запрос по мере необходимости.

Теперь, если все это звучит знакомо, тогда здорово. Протокол передачи гипертекста (HTTP), который определяет протокол связи через всемирную паутину, представляет собой реализацию абстрактного понятия архитектуры RESTful (или экземпляр класса REST, если вы фанатик ООП, как я). В этой реализации REST клиент и сервер взаимодействуют через GET, POST, PUT, DELETE и т.д., Которые являются частью универсального языка, и ресурсы могут указывать на использование URL-адресов.

17
ответ дан kal 31 марта '17 в 6:12 2017-03-31 06:12

Репрезентативная передача состояния (REST) ​​- это стиль архитектуры программного обеспечения, состоящий из рекомендаций и рекомендаций по созданию масштабируемых веб-сервисов. REST - это скоординированный набор ограничений, применяемых к разработке компонентов в распределенной системе гипермедиа, что может привести к более исполнительной и поддерживаемой архитектуры.

REST получила широкое признание в Интернете [цитата] как более простая альтернатива веб-сервисам на основе SOAP и WSDL. Системы RESTful обычно, но не всегда, обмениваются данными по протоколу передачи гипертекста с теми же HTTP-глаголами (GET, POST, PUT, DELETE и т.д.), Которые используются веб-браузерами для извлечения веб-страниц и отправки данных на удаленные серверы.

Архитектурный стиль REST был разработан группой технической архитектуры W3C (TAG) параллельно с HTTP 1.1 на основе существующего проекта HTTP 1.0. Всемирная паутина представляет собой самую большую реализацию системы, соответствующей архитектурному стилю REST.

Архитектурные ограничения

Архитектурные свойства REST реализуются путем применения конкретных ограничений взаимодействия к компонентам, соединителям и элементам данных. Официальные ограничения REST:

клиент-сервер

Единый интерфейс отделяет клиентов от серверов. Такое разделение проблем означает, что, например, клиенты не занимаются хранением данных, которые остаются внутренними для каждого сервера, так что мобильность клиентского кода улучшается. Серверы не связаны с пользовательским интерфейсом или пользовательским состоянием, поэтому серверы могут быть более простыми и масштабируемыми. Серверы и клиенты также могут быть заменены и разработаны независимо, если интерфейс между ними не изменяется.

Stateless

Коммуникация клиент-сервер дополнительно ограничена отсутствием клиентского контекста на сервере между запросами. Каждый запрос от любого клиента содержит всю информацию, необходимую для обслуживания запроса, а состояние сеанса хранится в клиенте. Состояние сеанса может быть передано сервером другой службе, такой как база данных, для поддержания постоянного состояния в течение определенного периода времени и разрешения аутентификации. Клиент начинает отправлять запросы, когда он готов перейти к новому состоянию. Хотя один или несколько запросов являются выдающимися, клиент считается находящимся в процессе перехода. Представление каждого состояния приложения содержит ссылки, которые могут быть использованы при следующей попытке клиента инициировать новый переход состояния.

Cacheable

Как и во Всемирной паутине, клиенты могут кэшировать ответы. Поэтому ответы должны, неявно или явно, определять себя как кэшируемые или нет, чтобы клиенты не могли повторно использовать устаревшие или ненадлежащие данные в ответ на дальнейшие запросы. Хорошо управляемое кэширование частично или полностью устраняет некоторые взаимодействия клиент-сервер, улучшая при этом масштабируемость и производительность.

Многоуровневая система

Клиент не может обычно указывать, подключен ли он непосредственно к конечному серверу или к посреднику на этом пути. Промежуточные серверы могут улучшить масштабируемость системы за счет включения балансировки нагрузки и предоставления общих кэшей. Они также могут применять политики безопасности.

Код по требованию (необязательно)

Серверы могут временно расширять или настраивать функциональные возможности клиента путем передачи исполняемого кода. Примерами этого могут быть скомпилированные компоненты, такие как Java-апплеты и клиентские скрипты, такие как JavaScript. "Код по требованию" является единственным необязательным ограничением архитектуры REST.

Равномерный интерфейс

Равномерное ограничение интерфейса является основополагающим для проектирования любой службы REST. Единый интерфейс упрощает и отделяет архитектуру, которая позволяет каждой части эволюционировать независимо.

14
ответ дан Dadaso Zanzane 04 февр. '15 в 9:11 2015-02-04 09:11

Я думаю, что спокойным является разделение состояния на более высокий уровень , используя интернет (протокол) как транспортный уровень без гражданства . Большинство других подходов смешивают вещи.

Это был лучший практический подход для обработки фундаментальных изменений в программировании в эпоху Интернета. Что касается фундаментальных изменений, Эрик Мейер обсуждает здесь: http://www.infoq.com/interviews/erik-meijer-programming-> . Он суммирует его как пять эффектов и представляет решение путем разработки решения на языке программирования. Решение также может быть достигнуто на уровне платформы или системы, независимо от языка. Спокойствие можно рассматривать как одно из решений, которое было очень успешным в текущей практике.

С спокойным стилем вы получаете и управляете состоянием приложения через ненадежный интернет. Если он не выполняет текущую операцию, чтобы получить правильное и текущее состояние, для поддержки приложения необходимо, чтобы он поддерживал нулевую валидацию. Если он не может манипулировать состоянием, он обычно использует несколько этапов подтверждения, чтобы все было в порядке. В этом смысле отдых не является само по себе полным решением, ему нужны функции в другой части стека веб-приложений для поддержки его работы.

Учитывая эту точку зрения, стиль отдыха на самом деле не привязан к интернету или веб-приложению. Это фундаментальное решение для многих ситуаций программирования. Это тоже не просто, это просто делает интерфейс очень простым и отлично справляется с другими технологиями.

Просто мой 2c.

Изменение: Еще два важных аспекта:

14
ответ дан minghua 03 июля '14 в 20:30 2014-07-03 20:30

Это удивительно длинная "дискуссия" и все же довольно запутанная, если не сказать больше.

ММО:

1) Нет такой вещи, как спокойное программирование, без большого сустава и большого количества пива:)

2) Репрезентативный перенос состояний (REST) ​​- это архитектурный стиль, указанный в очень хороший пост , который прекрасно объясняет ситуацию.

Множество @ копирует/вставляет действительную информацию, смешивая ее и добавляя некоторую путаницу. Люди говорят здесь о уровнях, о URI RESTFul (нет такого!), Применяйте методы HTTP GET, POST, PUT... REST не об этом или не только об этом.

Например, ссылки - неплохо иметь красиво выглядящий API, но в конце клиент/сервер действительно не заботится о ссылках, которые вы получаете/отправляете, это тот контент, который имеет значение.

В конце любой клиент RESTful должен иметь возможность использовать любой сервис RESTful, если известен формат содержимого.

14
ответ дан djodjo 13 янв. '17 в 17:02 2017-01-13 17:02

Старый вопрос, новый способ ответа. Есть много заблуждений об этой концепции. Я всегда стараюсь запомнить:

  1. Структурированные URL-адреса и методы/глаголы Http не являются определением спокойного программирования.
  2. JSON - это не спокойное программирование
  3. RESTful программирование не для API

Я определяю спокойное программирование как

Приложение успокаивается, если оно предоставляет ресурсы (являющиеся комбинацией элементов управления данными + переходы состояний) в типе носителя, который понимает клиент

Чтобы быть спокойным программистом, вы должны пытаться создавать приложения, позволяющие актерам делать что-то. Не только разоблачение базы данных.

Элементы управления переходом между состояниями имеют смысл только в том случае, если клиент и сервер договариваются о представлении ресурса по типу носителя. В противном случае нет способа узнать, что такое элемент управления, а что нет, и как выполнить элемент управления. То есть, если браузеры не знают тегов <form> в html, вам нечего будет отправлять в переходное состояние в вашем браузере.

Я не стремлюсь к саморекламе, но я углубляюсь в эти идеи в своем выступлении http://techblog.bodybuilding.com/2016/01/video-what-is-restful-200.html .

Выдержка из моего выступления о часто упоминаемой модели зрелости Ричардсона, я не верю в уровни, вы либо RESTful (уровень 3), либо нет, но то, что я хотел бы сказать об этом, - это то, что каждый уровень делает для вас на пути к RESTful

2019

ответ дан Chris DaMour 30 нояб. '16 в 23:05 2016-11-30 23:05

REST - это архитектурный стиль, основанный на веб-стандартах и протоколе HTTP (введен в 2000 году).

В архитектуре, основанной на REST, все является ресурсом (Пользователи, Заказы, Комментарии). Доступ к ресурсу осуществляется через общий интерфейс на основе стандартных методов HTTP (GET, PUT, PATCH, DELETE и т.д.).

В архитектуре REST у вас есть сервер REST, который обеспечивает доступ к ресурсам. Клиент REST может получить доступ и изменить ресурсы REST.

Каждый ресурс должен поддерживать общие операции HTTP. Ресурсы идентифицируются глобальными идентификаторами (обычно это URI).

REST позволяет ресурсам иметь разные представления, например, текст, XML, JSON и т.д. Клиент REST может запросить конкретное представление через HTTP-протокол (согласование контента).

Методы HTTP:

Способы PUT, GET, POST и DELETE типичны для архитектур на основе REST. В следующей таблице дается объяснение этих операций.

  • GET определяет доступ к чтению ресурса без побочных эффектов. Ресурс никогда не изменяется с помощью запроса GET, например, у запроса нет побочных эффектов (идемпотент).
  • PUT создает новый ресурс. Он также должен быть идемпотентным.
  • DELETE удаляет ресурсы. Операции являются идемпотентными. Они могут повторяться, не приводя к разным результатам.
  • POST обновляет существующий ресурс или создает новый ресурс.
11
ответ дан Imran 15 сент. '17 в 22:47 2017-09-15 22:47

REST === HTTP-аналогия неверна, пока вы не будете подчеркивать, что она "ДОЛЖНА" быть управляемой HATEOAS .

Рой сам очистил его здесь .

API REST должен вводиться без предварительного знания за пределами исходного URI (закладки) и набора стандартизованных типов медиа, которые подходят для целевой аудитории (т.е. Ожидается, что их понимает любой клиент, который может использовать API). С этого момента все переходы состояния приложения должны управляться выбором клиентом предоставленных сервером вариантов, которые присутствуют в полученных представлениях или подразумеваются пользователями, манипулирующими этими представлениями. Переходы могут быть определены (или ограничены) знаниями клиентов о типах медиа и механизмах обмена ресурсами, которые могут быть улучшены "на лету" (например, код по требованию).

[Сбой здесь означает, что внеполосная информация управляет взаимодействием, а не гипертекстом.]

11
ответ дан lokesh 03 июня '16 в 14:35 2016-06-03 14:35

Не существует такого понятия, как "программирование RESTful" как таковое. Лучше было бы назвать RESTful парадигму или даже лучшую архитектуру RESTful. Это не язык программирования. Это парадигма.

Из Википедии :

При вычислении репрезентативная передача состояния (REST) ​​является архитектурный стиль, используемый для веб-разработки.

10
ответ дан ACV 24 авг. '16 в 20:57 2016-08-24 20:57

REST означает Передача состояния представления .

Он опирается на безвизовый, клиент-серверный, кэшируемый протокол связи - и практически во всех случаях используется протокол HTTP.

REST часто используется в мобильных приложениях, веб-сайтах социальных сетей, инструментах mashup и автоматизированных бизнес-процессах. Стиль REST подчеркивает, что взаимодействие между клиентами и услугами улучшается за счет ограниченного числа операций (глаголов). Гибкость обеспечивается путем присвоения ресурсам (существительным) собственных уникальных индикаторов универсальных ресурсов (URI).

Введение в Rest

10
ответ дан GowriShankar 10 нояб. '14 в 16:37 2014-11-10 16:37

Говорить - это не просто обмен информацией. Протокол фактически разработан таким образом, чтобы не было необходимости говорить. Каждая сторона знает, какова их конкретная работа, потому что она указана в протоколе. Протоколы обеспечивают чистый обмен информацией за счет любых изменений в возможных действиях. С другой стороны, разговор позволяет одной стороне спросить, какие дальнейшие действия могут быть предприняты другой стороной. Они могут даже задать один и тот же вопрос дважды и получить два разных ответа, поскольку государство другой стороны, возможно, изменилось промежуточный период. Обсуждение - архитектура RESTful . Филдинг-тезис определяет архитектуру, которой следовало бы следовать, если бы хотелось, чтобы машины разговаривали друг с другом, а не просто обменивались данными.

10
ответ дан qmckinsey 06 дек. '14 в 9:54 2014-12-06 09:54

REST определяет 6 архитектурных ограничений, которые делают любой веб-сервис - настоящим RESTful API .

  1. Равномерный интерфейс
  2. Клиент-сервер
  3. Stateless
  4. Cacheable
  5. Многослойная система
  6. Код по запросу (необязательно)

https://restfulapi.net/rest-architectural-constraints/

9
ответ дан Jaider 03 окт. '17 в 0:23 2017-10-03 00:23

Точка покоя состоит в том, что, если мы соглашаемся использовать общий язык для основных операций (http-глаголов), инфраструктура может быть сконфигурирована так, чтобы понимать их и правильно оптимизировать, например, используя кэширующие заголовки для реализации кеширование на всех уровнях.

При правильно выполненной восстановленной операции GET не имеет значения, поступает ли информация из вашей серверной БД, вашей memcache сервера, CDN, прокси-кеша, кеша браузера или локального хранилища вашего браузера. Можно использовать быстродоступный, доступный до настоящего времени источник.

Говоря, что Rest - это просто синтаксическое изменение от использования запросов GET с параметром действия с использованием доступных глаголов http, похоже, что оно не имеет преимуществ и чисто косметическое. Дело в том, чтобы использовать язык, который может быть понят и оптимизирован каждой частью цепочки. Если ваша операция GET имеет действие с побочными эффектами, вам нужно пропустить все кеширование HTTP или вы получите несогласованные результаты.

9
ответ дан Benoit Essiambre 02 февр. '12 в 2:52 2012-02-02 02:52

Что такое тестирование API ?

API-тестирование использует программирование для отправки вызовов в API и получения доходности. Это тестирование рассматривает тестируемый сегмент как черный ящик. Цель тестирования API состоит в том, чтобы подтвердить правильное выполнение и ошибочное рассмотрение части, предшествующей ее координации, в приложение.

API REST

ОТДЫХ: Передача репрезентативного состояния.

  • Его расположение функций, на которых тестеры выполняют запросы и получают ответы. В REST API взаимодействия осуществляются по протоколу HTTP.
  • REST также позволяет общаться между компьютерами друг с другом по сети.
  • Для отправки и получения сообщений он включает в себя использование HTTP-методов и не требует строгого определения сообщений, в отличие от веб-служб.
  • Сообщения REST часто принимают форму либо в форме XML, либо в Object Object Notation (JSON).

4 Используемые методы API:

  1. GET: - предоставляет доступ только к ресурсу только для чтения.
  2. POST: - Используется для создания или обновления нового ресурса.
  3. PUT: - Используется для обновления или замены существующего ресурса или создания нового ресурса.
  4. DELETE: - используется для удаления ресурса.

Шаги для тестирования API вручную: -

Чтобы использовать API вручную, мы можем использовать API-интерфейсы REST API на основе браузера.

  1. Установите плагин POSTMAN (Chrome)/REST (Firefox)
  2. Введите URL-адрес API
  3. Выберите метод REST
  4. Выберите контент-заголовок
  5. Введите запрос JSON (POST)
  6. Нажмите, чтобы отправить
  7. Он вернет выходной отклик

Шаги по автоматизации API REST

5
ответ дан kkashyap1707 01 авг. '16 в 9:42 2016-08-01 09:42

Это очень мало упоминается повсюду, но модель зрелости Ричардсона является одним из лучших способов судить о том, насколько Restful является одним API. Подробнее об этом здесь:

Модель зрелости Ричардсона

5
ответ дан kg11 29 авг. '17 в 14:55 2017-08-29 14:55
  • 1
  • 2

Другие вопросы по меткам или Задайте вопрос