REST'i anlama: Verbs, Hata Kodları və Doğrulama

Mən web applications, verilənlər bazaları və PHP-based CMS-də default funksiyaları ətrafında API bağlamaq üçün bir yol axtarıram.

Ətrafına baxdım və bir neçə skelet tapdıq. Soruşmamın yanına gələn Tonic , REST'in quruluşunu çox sevirəm, çünki çox işıqlıdır.

Mən REST-in sadəliyə ən uyğun olduğunu etiraf edirəm və bunun üzərində bir API mimarisi yaratmaq istərdim. Mən əsas prinsipləri başa düşməyə çalışıram və hələ də başa düşmürəm. Buna görə bir sıra suallar.

1. Bunu doğru anlayırmı?

Gəlin mənim "istifadəçilərim" var. Məsələn, bir çox URI-ni konfiqurasiya edə bilərəm:

 /api/users when called with GET, lists users /api/users when called with POST, creates user record /api/users/1 when called with GET, shows user record when called with PUT, updates user record when called with DELETE, deletes user record 

Bu günə qədər RESTful architecture düzgün təmsil edirmi?

2. Daha çox fe'llərə ehtiyacım var

Yaratmaq, yeniləmək və silmək nəzəriyyədə kifayət qədər ola bilər, amma praktikada daha çox fe'llərə ehtiyacım var. Mən anlayıram ki, bunlar bir yeniləmə tələbinə çevrilə biləcək şeylərdir, amma müəyyən qaytarma kodlarına sahib ola biləcək xüsusi əməliyyatlardır və mən hamısını bir hərəkətə atmaq istəmirəm.

Bunlardan bəziləri istifadəçinin nümunəsində nəzərə gəlir:

 activate_login deactivate_login change_password add_credit 

RESTful URL mimarisi kimi fəaliyyətləri necə ifadə edə bilərəm?

Mənim instinkt, məsələn, bir URL üçün GET çağırış etməkdir

 /api/users/1/activate_login 

və status kodunun qaytarılmasını gözləyin.

Bu, HTTP fiillerini istifadə etmək fikrindən uzaqdır. Sizcə nədir?

Hata mesajları və kodları necə qaytarmaq olar?

REST gözəlliklərinin çoxu standart HTTP üsullarından istifadə edir. Bir səhv baş verərsə, mən 3xx, 4xx və ya 5xx səhv statusu kodu olan bir başlıq verirəm. Səhvin ətraflı təsviri, mən bədəndən istifadə edə bilərəmmi? (Sağ?). Hər şey yaxşı gedir. Ancaq səhvən daha dəqiq bir şəkildə (məsələn, "verilənlər bazasına bağlanıla bilmədi" və ya "verilənlər bazasına yanlış daxil olmağı" deyə bilər) öz səhv kodunu necə ötürə bilərsən? Mesajı birlikdə bədənə qoysam, onu daha sonra sökmək məcburiyyətindəyəm. Bu cür məhsullar üçün standart bir başlıq varmı?

4. Kimlik idarəsi necə aparılır?

  • API əsaslı identifikasiyası REST prinsiplərinə əsasən necə görünür?
  • REST-in prinsipinin açıq şəkildə pozulması istisna olmaqla, REST-in müştərisini təsdiqləyərkən iclaslardan istifadə etməyinizə qarşı hər hansı bir güc varmı? (Bu zarafatların yalnız yarısı, seans əsaslı autentifikasiya mövcud infrastrukturumla yaxşı işləyəcəkdir).
544
04 янв. Pekka tərəfindən hazırlanıb 04 İyun 2010-01-04 22:55 '10 at 10:55 pm 2010-01-04 22:55
@ 10 cavab

Bir neçə gün sonra bu sualları anladım, ancaq bəzi fikirlər əlavə edə bilərəm. Ümid edirəm ki, bu, RESTANT müəssisəniz üçün faydalı ola bilər.


1 nöqtə: Düzgün başa düşürəmmi?

Düzgün başa düşdünüz. Bu RESTful memarlıq düzgün təmsil edir. Vikipediyadan aşağıdakı matrisi sizin isim və fe'llərinizi təyin etmək üçün çox faydalı tapa bilərsiniz:


URI Kolleksiyası ilə işləyərkən: http://example.com/resources/

  • GET . Əlavə naviqasiya üçün toplama üzvlərini URI üzvləri ilə birlikdə qeyd edin. Məsələn, satış üçün bütün avtomobilləri sıralayın.

  • PUT . Qiymət "bütün kolleksiyanı başqa bir kolleksiya ilə əvəz etmək" kimi təyin olunur.

  • POST . Identifikatorun avtomatik toplanması ilə təyin etdiyi toplusunda yeni bir giriş yaradın. Yaradılmış identifikator adətən bu əməliyyata qaytarılmış məlumatların bir hissəsi kimi daxil edilir.

  • REMOVE . Qiymət "bütün kolleksiyanı silmək" kimi müəyyən edilir.


İstifadəçi URI ilə işləyərkən: http://example.com/resources/7HOU57Y

  • GET : Müvafiq MIME növündə ifadə olunan toplama elementinin alıcının görünüşünü alın.

  • PUT . Koleksiyanın ünvan elementini yeniləyin və ya göstərilən ID ilə yaradın.

  • POST . Aradan qaldırılan maddə ayrı bir kolleksiya kimi işləyir və yeni bir tabeçilik yaradır.

  • REMOVE : toplama elementinin elementini silin.


2 nöqtə: daha çox fe'llərə ehtiyacım var

Ümumiyyətlə, daha çox felse ehtiyacınız olduğunu düşündüyünüz zaman, həqiqətən, resursların yenidən təsbit edilməsi lazımdır. REST-də həmişə bir qaynaq və ya resurs setində hərəkət etdiyini unutmayın. Bir qaynaq olaraq seçdiyiniz API üçün çox əhəmiyyətlidir.

Girişi aktivləşdir / ləğv edin . Yeni bir seans yaratsanız, "seans" ı bir qaynaq olaraq nəzərdən keçirməlisiniz. Yeni bir sessiya yaratmaq üçün, http://example.com/sessions/ üçün POST istifadə edin və bədənində etimadnaməsini http://example.com/sessions/ . Bunu başa çatdırmaq üçün http://example.com/sessions/SESSION_ID əvvəl PUT və ya DELETE (seans tarixini saxlamağınızdan asılı olaraq) istifadə http://example.com/sessions/SESSION_ID .

Şifrəni dəyiş: Bu dəfə resurs "istifadəçi" dir. Bədəninizdə köhnə və yeni parollarla http://example.com/users/USER_ID üçün bir PUT lazımdır. Bir istifadəçi qaynağında hərəkət edirsiniz və dəyişdirmək üçün şifrə yalnız yeniləmə tələbidir. Bu relational verilənlər bazasında UPDATE bəyanatına çox oxşardır.

Mənim instinktim /api/users/1/activate_login kimi bir URL-ə çağırmaq olar

Bu REST-in ən əsas prinsipinə ziddir: HTTP fiillerinin düzgün istifadə edilməsi. Hər hansı bir GET tələbi heç vaxt yan təsiri olmamalıdır.

Məsələn, bir GET sorğusu verilənlər bazasında heç bir seans yaratmır, yeni bir seans kimliyi olan cookie-i qaytarır və ya serverdə qalıqları buraxmır. GET vergisi verilənlər bazası motorunda SELECT ifadəsinə bənzəyir. GET-verb istifadə edərək, istənilən sorğunun statik bir veb-səhifəsi istənilən eyni parametrlərlə tələb olunduğu zaman önbelleğe alınması lazım olduğunu unutmayın.


Nöqtə 3: Hata mesajlarını və kodlarını necə qaytarmaq olar?

HTTP 4xx və ya 5xx status kodlarını səhv kateqoriyalar kimi nəzərdən keçirin. Bədəndə bir səhv inkişaf edə bilər.

Verilənlər bazasına qoşulmaq mümkün deyil: / Veritabanına yanlış giriş . Bu tip səhvlər üçün adətən səhv 500 istifadə etməlisiniz. Bu bir server tərəfi səhvidir. Müştəri yanlış bir şey etmədim. 500 səhv adətən "təkrarlanabilir" sayılır. yəni müştəri eyni tələbi təkrarlaya və server ilə problemləri düzəltməsindən sonra uğurlu olmasını gözləyə bilər. Müştərinin bəzi kontekst ilə təmin edə bilməsi üçün detalları bədənə qoyun.

Səhvlərin başqa bir kateqoriyası, ümumiyyətlə müştərinin səhv bir şey etdiyini göstərir olan 4xx ailəsidir. Xüsusilə, bu səhvlər kateqoriyası adətən müştəri üçün tələbi təkrarlamaq lazım olmadığını göstərir, çünki bu, əbədi uğursuzluğa davam edəcəkdir. yəni müştəri bu tələbi təkrarlamadan əvvəl bir şey dəyişdirməlidir. Məsələn, "Resurs tapılmadı" (HTTP 404) və ya "Failed request" (HTTP 400) səhvləri bu kateqoriyaya daxildir.


Nöqtə 4: Kimlik idarəsi necə edilir

1-ci addımda göstərildiyi kimi, istifadəçi kimlik doğrulaması yerinə, bir sessiya yaratmağı düşünmək isteyebilirsiniz. Müvafiq HTTP statusu kodu ilə yanaşı, yeni bir "Session ID" göndəriləcək (200: Access icazə və ya 403: Access reddedildi).

Sonra RESTful server soruş: "Bu sessiya id üçün bir resurs əldə edə bilərsiniz?".

Kimliklə təsdiqlənmə rejimi yoxdur. REST statusu yoxdur: bir sessiya yaratırsınızsa, bu sessiya identifikatorunu bir parametr kimi istifadə edərək serverdən tələb edirsiniz və çıxışdan çıxdığınız zaman sessiyanı bitirir və ya sonlandırırsınız.

569
07 янв. Daniel Vassallo 07 Jan 2010-01-07 22:13 '10 at 10:13 PM 2010-01-07 22:13

Sadəcə qoyun, bunu geri qaytarın.

Bunu istifadə etməyiniz hansı URL-lərə müraciət etməməlisiniz. Sisteminiz üçün hansı resurslara ehtiyac duyduğunuzdan və bu qaynaqları necə təqdim edəcəyinizdən, həmçinin resursların və ərizə ilə dövlət arasındakı qarşılıqlı əlaqələrin verildikdən sonra URL'ler effektiv şəkildə "pulsuz" olacaqdır.

Roy Fielding'den sitat gətirmək

REST API, sürücülük vəziyyəti və ya mövcud standart media tipləri üçün geniş əlaqələr adlarını və / və ya hiper mətn biçimlendirmesini təyin etmək üçün resursları və tətbiqləri təmsil etmək üçün istifadə olunan media növünü müəyyənləşdirmək üçün demək olar ki, bütün təsvir işlərini sərf etməlidir. URI'ların necə istifadə ediləcəyini təsvir edən hər hansı bir səy media növü üçün (və əksər hallarda təyin edilmiş media tipləri üçün) işləmə qaydasında tam şəkildə müəyyən edilməlidir. [Disclaimer burada buraxılmış məlumatlar hipermetin əvəzinə qarşılıqlı əlaqəyə gətirib çıxarır.]

İnsanlar həmişə bir URI ilə başlayır və bunun bir həll olduğuna inanırlar və sonra REST arxitekturasında əsas konsepsiyanı, xüsusilə, yuxarıda göstərildiyi kimi qaçırırlar: "Buradakı bir səhv budur ki, məlumatdan kənar məlumatlar əvəzinə hipertext qarşılıqlı əlaqələrə gətirib çıxarır".

Dürüstcə, bir çox insanlar URI-lər və bəzi GET, PUT və POST qruplarını görür və REST-in asan olduğunu görürlər. REST asan deyil. HTTP üzərindən RPC asandır; hərəkətli məlumat blokları əvvəlki və sonrakı HTTP payloadları vasitəsilə proxied olunur. Ancaq REST bunun xaricinə çıxır. REST protokolu agnostikdir. HTTP çox məşhurdur və REST sistemlərinə uyğun gəlir.

REST multimediya növləri, onların tərifləri və bir tətbiqin bu resurslar üçün hipermetin (səmərəli keçidlər) vasitəsilə hərəkətlərini necə idarə etdiyini göstərir.

REST sistemlərində media növlərinin fərqli bir anlayışı var. Bəziləri xüsusi proqramları üstün tuturlar, digərləri mövcud media növləri tətbiq üçün uyğun rollara yüksəltmək istəyirlər. Məsələn, bir tərəfdən, XHTML kimi təqdimat kimi istifadə etmək əvəzinə, mikroformatlar və digər mexanizmlər vasitəsilə istifadə etmək əvəzinə tətbiqiniz üçün nəzərdə tutulmuş müəyyən XML şemalarınız var.

Hər iki yanaşma da öz mövqeyinə malikdir, məncə XHTML həm insan nəzarətində, həm də maşın nəzarətində olan maşınlarla üst-üstə düşən ssenarilərdə çox yaxşı işləyir, mən daha yaxşı hiss etdiyim ilk xüsusi məlumat maşınları maşın və maşın arasındakı qarşılıqlı əlaqəni asanlaşdırır. Məhsulun formatlarının yaxşılaşdırılması məzmunda razılığa gələ biləcəyinə inanıram. "tətbiq / xml + yourresource" proqramı, "ərizə / xhtml + xml" -dən çox media növü kimi daha spesifikdir, çünki sonuncu bir çox yüklənmələrə tətbiq oluna bilər, ya da maşın müştərisinin həqiqətən maraqlandığı bir şey ola bilər və ya ola bilməz introspeksiya olmadan müəyyən edə bilmir.

Bununla belə, XHTML veb-brauzerlərin və göstərilmənin çox vacib olduğu vebdə çox yaxşı işləyir (aydındır).

Tətbiqiniz belə qərarlarla sizə kömək edəcəkdir.

REST sisteminin dizayn prosesinin bir hissəsi sisteminizdə birinci sinif resursların aşkarlanması və əsas resurslarla əməliyyatları dəstəkləmək üçün lazım olan dəstək resurslarıdır. Resurslar aşkar edildikdən sonra, bu qaynaqların təmsil edilməsi, eləcə də dövlət diaqramları, növbəti vəzifə olduğundan, təqdimatlarda köprü mətnləri vasitəsilə resursların axını göstərir.

Hiper mətn sistemindəki hər bir resurs təmsilçisinin, həm də faktiki mənbə təmsilçiliyi və resurs üçün mövcud dövlət keçişlərini birləşdirdiyini xatırladırıq. Hər qaynağı grafiğin bir düyüsünü nəzərdən keçirin və bağlantılar digər dövlətlər üçün bu nodu tərk edən xətlərdir. Bu əlaqələr müştərilərə nə edə biləcəyini deyil, həm də onlar üçün nə tələb olunur (yaxşı bir link kimi URI və tələb olunan media növünü birləşdirir).

border=0

Məsələn, ola bilər:

 <link href="http://example.com/users" rel="users" type="application/xml+usercollection"/> <link href="http://example.com/users?search" rel="search" type="application/xml+usersearchcriteria"/> 

Sənədlərinizdə "istifadəçilər" və media növü "application / xml + youruser" adlı rel field var.

Bu əlaqələr lazımsız görünə bilər, hamısı eyni URI ilə əlaqə saxlayır. Ancaq bu deyil.

Bu, "istifadəçilər" əlaqəsi üçün istifadəçilər kolleksiyasına aiddir və kollektivlə işləmək üçün bir interfeysdən istifadə edə bilərsiniz (bunları qəbul etmək üçün GET, bütün bunları silmək üçün DELETE və s.).

Bu URL-yə POST göndərirsinizsə, sənəddə istifadəçinin bir nüsxəsini ehtiva edən "tətbiq / xml + usercollection" sənədini təqdim etməlisiniz, belə ki, bir istifadəçi əlavə edə bilərsiniz və ya bir dəfəyə əlavə edə bilərsiniz. Yəqin ki, sənədləriniz sadəcə bir kolleksiya yerinə bir növ istifadəçi köçürə bilər.

Tətbiqin "axtarış" linki və onun media növü ilə müəyyən edilmiş axtarışı yerinə yetirmək üçün nə tələb etdiyini görə bilərsiniz. Axtarış media növü üçün sənədlər bunun necə olacağını və nəticədə nə gözləməyiniz barədə sizə məlumat verəcəkdir.

Buradakı nəticə, ümumiyyətlə, vacib deyildir. Ərizə müştəriləri deyil, URI-nı nəzarət edir. Bir neçə "giriş nöqtələrinə" əlavə olaraq, müştəriləriniz tətbiq üçün nəzərdə tutulan URI-lərə əməl etməlidirlər.

Müştəri mətbuatın növlərini manipulyasiya etmək və şərh etmək üçün necə bilməli, lakin onun getdiyi yerdən narahat olmamalıdır.

Bu iki əlaqə, müştərilərin gözündə semantik olaraq eynidır:

 <link href="http://example.com/users?search" rel="search" type="application/xml+usersearchcriteria"/> <link href="http://example.com/AW163FH87SGV" rel="search" type="application/xml+usersearchcriteria"/> 

Beləliklə, resurslarınıza diqqət yetirin. Tətbiqdə dövlət keçişlərinizə və bunun ən yaxşı şəkildə əldə olunmasına diqqət yetirin.

74
08 янв. Cavab Will Hartung Jan 08 tərəfindən verilir 2010-01-08 05:39 '10 at 5:39 'da 2010-01-08 05:39

İndi 1 : indi bu gözəl. Yeni yaradılan istifadəçinin URI'sini Yeri: başlığı POST cavabının bir hissəsi kimi, 201 Yaradılma statusu kodu ilə birlikdə qaytarmağı unutmayın.

re 2 : GET aktivləşdirməsi pis bir fikirdir, URI-da verb daxil olmaqla dizayner qoxusu. GET'deki forma geri dönmek isteyebilirsiniz. Veb tətbiqi ilə təqdimat düyməsinə malik HTML forması olacaq; API istifadə etsəniz, bir hesabı aktivləşdirmək üçün PUT üçün URI olan bir görünüşü qaytarmaq isteyebilirsiniz. Əlbəttə, istifadəçilər üçün POST-ə cavab olaraq bu URI daxil edə bilərsiniz. PUT istifadə edərək, sorğunuzun idempotent olduğunu təmin edir, yəni müştərinin müvəffəqiyyətdən əmin olmadığı halda yenidən təhlükəsiz olaraq göndərilə bilər. Ümumiyyətlə, öz fe'llərinizə hansı qaynaqlara keçə biləcəyinizi ("fiillərin yuyulması" kimi) düşünün. Şəxsi hərəkətlərinizlə ən sıx bağlı olan üsulları özünüzə soruşun. Məsələn, change_password → PUT; deaktivləşdirmək → Bəlkə DELETE; add_credit → POST və ya PUT mümkündür. Müvəkkilinizi təqdimatlarında onlara daxil etməklə müvafiq URI-lərə yönləndirin.

3. Dünya səviyyəsində standardizasiyaya layiq olduqları qədər universal saymırsınızsa, yeni status kodları icad etməyin. Ən uyğun status kodunu (RFC 2616-da hamısını oxuyun) istifadə etməyə çalışın. Cavab orqanında əlavə məlumatlar əlavə edin. Yeni bir status kodu ilə gəlmək istədiyinizə əmin olduğunuz halda yenidən düşünün; hələ də inanırsınızsa, ən azı istədiyiniz kateqoriyanı seçin (1xx → OK, 2xx → informasiya, 3xx → redirection, 4xx-> müştəri səhvi, 5xx xətası → server). Yeni status kodlarının yaradılması pis bir fikirdir?

4. Mümkünsə, HTTP daxilində quraşdırılmış identifikasiyası çərçivəsini istifadə edin. GData'da Google kimlik doğrulama metodunu yoxlayın. Ümumiyyətlə, URI'larınıza API düymələri əlavə etmir. Ölçeklenebilirliği ve destekleme önbelleklemesini artırmak üçün seanslardan kaçınmağa çalışın - istekte olan cavab daha əvvəl gerçekleştiğinden dolayı farklıysa, genellikle belirli bir server örneğine bağlıyorsunuz. Oturum vəziyyətini müştəri dövlətinə daxil etmək daha yaxşıdır (məsələn, sonrakı istəklərin bir hissəsini təşkil edin) və ya açıq olaraq onu bir qaynaq (server) vəziyyətinə çevirin, yəni, Öz URI ilə təmin edin.

29
04 янв. Cavab Stefan Tilkov tərəfindən 04 yanvar 2010-01-04 23:39 '10 at 11:39 'da 2010-01-04 23:39

1. Öz resurslarını, IMHO-nu necə yaratmaq barədə düzgün fikirləriniz var. Mən bir şey dəyişməyəcəyəm.

2. HTTP'yi çox sayda fiil ilə genişləndirməyə çalışmaq yerinə, təklif olunan fe'llərin əsas HTTP metodlarına və resurslarına salınmasını düşünün. Məsələn, activate_login verbinin əvəzinə sadə bir boolean olan: /api/users/1/login/active kimi resursları konfiqurasiya edə bilərsiniz. Girişi aktivləşdirmək üçün sadəcə "doğru" və ya 1 və ya başqa bir şey deyildiyi yerə PUT . Ləğv etmək üçün PUT sənəd boşdur və ya 0 və ya yanlış deyir.

Eynilə, PUT /api/users/1/password dəyişmək və ya təyin etmək.

Bir şey əlavə etməlisiniz (məsələn, kredit), POST baxımından düşünün. Məsələn, əlavə edilmiş kreditlərin sayını ehtiva edən bir cədvəllə, /api/users/1/credits kimi bir resurs üçün bir POST edə bilərsiniz. Eyni PUT bir PUT əlavə etmək üçün dəyərin üzərində yazmaq üçün istifadə edilə bilər. Bədəndə mənfi bir ədəd olan POST çıxacaq və s.

3. Əsas HTTP statusu kodlarının yayılmamasına şiddətlə gəlirəm. Vəziyyətinizə tam uyğun gələn birini tapa bilmirsəniz, ən yaxşısını seçin və səhv məlumatlarını cavab orqanına yerləşdirin. Ayrıca, HTTP başlıqlarının genişlənə biləcəyini xatırlayın; Tətbiq etdiyiniz bütün xüsusi başlıqları müəyyən edə bilər. Məsələn, çalışdığım bir ərizə bir neçə şərtdə 404 Not Found . Müvəkkil bu səbəbdən cavab orqanını təhlil etməyə məcbur etmək əvəzinə sadəcə olaraq, yeni X-Status-Extended başlığını əlavə etdi ki, bu da bizim mülkiyyət statusu kodlarının uzadılmasını əks etdirdi. Beləliklə, cavabınızı aşağıdakı kimi görə bilərsiniz:

 HTTP/1.1 404 Not Found X-Status-Extended: 404.3 More Specific Error Here 

Beləliklə, veb brauzer kimi bir HTTP müştəri hələ də müntəzəm 404 kodu ilə nə edəcəyini biləcək və daha inkişaf etmiş bir HTTP müştəri daha ətraflı məlumat almaq üçün X-Status-Extended başlığını seçə bilər.

4. Kimlik doğrulaması üçün mümkün olduğunda HTTP kimlik doğrulamasını istifadə edirəm. Ancaq IMHO cookie-based identifikasiyası ilə yanlış bir şey yoxdur, əgər bu sizin üçün daha asan olarsa.

20
05 янв. Cavab friedo Jan 05 tərəfindən verilir 2010-01-05 00:28 '10 at 0:28 2010-01-05 00:28

Aşağıdakı nümunələrdə mən istifadə edərdim:

activate_login

POST /users/1/activation

deactivate_login

DELETE /users/1/activation

change_password

PUT /passwords (это предполагает, что пользователь аутентифицирован)

add_credit

POST /credits (это предполагает, что пользователь аутентифицирован)

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

DELETE /users/1.xml

Вы отправите ответ обратно в XML, то же самое будет верно для JSON и т.д.

Для аутентификации вы должны использовать http-аутентификацию.

11
ответ дан jonnii 04 янв. '10 в 23:07 2010-01-04 23:07

Основы REST

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

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

  • HTTP 1.1
    • определения методов
    • определения кода состояния
    • заголовки управления кэшем Заголовки
    • accept и content-type
    • заголовки auth
  • IRI (utf8 URI )
  • тело (выберите один)
    • зарегистрированный специфичный для приложения тип MIME, например. лабиринт + xml
    • тип MIME поставщика, например. vnd.github + json
    • общий тип MIME с
      • специфический для приложения RDF vocab, например. ld + json и hydra , schema.org
      • конкретный профиль приложения, например. hal + json и параметр профиля профиля (я думаю)
  • гиперссылок
    • что должно содержать их (выберите один)
      • отправка заголовков ссылок
      • отправка ответа гипермедиа, например. html, atom + xml, hal + json, ld + json hydra и т.д.
    • семантика
      • использовать отношения ссылок IANA и, возможно, настраиваемые отношения ссылок
      • использовать специфический для приложения RDF vocab

У REST есть ограничение без состояния, которое заявляет, что связь между службой REST и клиентом должна быть неактивной. Это означает, что служба REST не может поддерживать состояния клиента, поэтому вы не можете иметь хранилище сеансов на стороне сервера. Вы должны аутентифицировать каждый запрос. Так, например, HTTP basic auth (часть стандарта HTTP) в порядке, потому что он отправляет имя пользователя и пароль с каждым запросом.

Чтобы ответить на ваши вопросы

  • Да, это может быть.

    Как раз упомянуть, клиенты не заботятся о структуре IRI, они заботятся о семантике, потому что они следуют за ссылками, связанными с отношениями ссылок или связанными данными (RDF).

    Единственное, что важно для IRI, заключается в том, что один IRI должен идентифицировать только один ресурс. Каждому ресурсу, как и пользователю, разрешено иметь много разных IRI.

    Это довольно просто, почему мы используем интересные IRI, такие как /users/123/password ; гораздо проще написать логику маршрутизации на сервере, когда вы понимаете IRI, просто прочитав ее.

  • У вас больше глаголов, таких как PUT, PATCH, OPTIONS и даже больше, но вам не нужно больше их... Вместо добавления новых глаголов вам нужно научиться добавлять новые ресурсы.

    activate_login -> PUT /login/active true deactivate_login -> PUT /login/active false change_password -> PUT /user/xy/password "newpass" add_credit -> POST /credit/raise {details: {}}

    (Вход в систему не имеет смысла с точки зрения REST из-за ограничения без сохранения.)

  • Ваши пользователи не заботятся о том, почему проблема существует. Они хотят знать только, если есть успех или ошибка, и, вероятно, сообщение об ошибке, которое они могут понять, например: "Извините, но мы не смогли сохранить ваше сообщение" и т.д.

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

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

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

Связанная литература

10
ответ дан inf3rno 18 сент. '14 в 1:24 2014-09-18 01:24
  • Используйте пост, когда вы не знаете, как будет выглядеть новый URI ресурса (вы создаете нового пользователя, приложение назначит нового пользователя его идентификатор), PUT для обновления или создания ресурсов, которые вы знаете, как они будут (пример: PUT/myfiles/thisismynewfile.txt)
  • возвращает описание ошибки в теле сообщения
  • Вы можете использовать HTTP-аутентификацию (если это достаточно) Веб-сервисы должны быть stateles
6
ответ дан Arjan 04 янв. '10 в 23:06 2010-01-04 23:06

Я бы предложил (в качестве первого прохода), что PUT должен использоваться только для обновления существующих объектов. POST следует использовать для создания новых. yəni.

 /api/users when called with PUT, creates user record 

мне не нравится. Остальная часть вашего первого раздела (использование re-verb) выглядит логично.

5
ответ дан Brian Agnew 04 янв. '10 в 23:03 2010-01-04 23:03

Подробный, но скопированный из спецификации метода HTTP 1.1 в http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

9.3 GET

Метод GET означает получение любой информации (в форме объекта), идентифицируемой Request-URI. Если Request-URI ссылается на процесс создания данных, то полученные данные должны быть возвращены в качестве объекта в ответе, а не в исходном тексте процесса, если только этот текст не является результатом процесса.

Семантика метода GET изменяется на "условное GET", если сообщение запроса включает в себя поле If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match или If-Range, Условный метод GET запрашивает передачу объекта только при обстоятельствах, описанных условным полем заголовков. Условный метод GET предназначен для уменьшения ненужного использования сети, позволяя обновлять кэшированные объекты, не требуя нескольких запросов или передачи данных, уже сохраненных клиентом.

Семантика метода GET изменяется на "частичное GET", если сообщение запроса включает поле заголовка Range. Частичные запросы GET передают только часть объекта, как описано в разделе 14.35. Частичный метод GET предназначен для уменьшения ненужного использования сети, позволяя завершить частично восстановленные объекты без переноса данных, уже находящихся у клиента.

Ответ на запрос GET можно кэшировать тогда и только тогда, когда он отвечает требованиям кэширования HTTP, описанным в разделе 13.

См. раздел 15.1.3 для соображений безопасности при использовании для форм.

9.5 POST

Метод POST используется для запроса, чтобы исходный сервер принял объект, заключенный в запросе, в качестве нового подчиненного ресурса, идентифицированного Request-URI в строке запроса. POST предназначен для обеспечения единообразного метода для покрытия следующих функций:

  - Annotation of existing resources; - Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles; - Providing a block of data, such as the result of submitting a form, to a data-handling process; - Extending a database through an append operation. 

Фактическая функция, выполняемая методом POST, определяется сервером и обычно зависит от Request-URI. Опубликованный объект подчинен этому URI таким же образом, что файл подчинен каталогу, содержащему его, новостная статья подчинена группе новостей, на которую она отправлена, или запись подчинена базе данных.

Действие, выполняемое методом POST, может не привести к ресурсу, который может быть идентифицирован с помощью URI. В этом случае либо 200 (OK), либо 204 (No Content) - это соответствующий статус ответа, в зависимости от того, включает ли ответ объект, который описывает результат.

Если ресурс был создан на исходном сервере, ответ должен быть равен 201 (создан) и содержать объект, который описывает статус запроса и ссылается на новый ресурс, и заголовок Location (см. раздел 14.30).

Ответы на этот метод не могут быть кэшируемыми, если только ответ не включает соответствующие поля заголовка Cache-Control или Expires. Тем не менее, ответ 303 (см. Раздел "Другие" ) можно использовать для направления агента пользователя для получения кэшируемого ресурса.

Запросы POST ДОЛЖНЫ подчиняться требованиям к передаче сообщений, изложенным в разделе 8.2.

См. раздел 15.1.3 для соображений безопасности.

9.6 PUT

Метод PUT запрашивает, чтобы закрытый объект хранился в запрошенном Request-URI. Если Request-URI ссылается на уже существующий ресурс, закрытый объект СЛЕДУЕТ считаться модифицированной версией той, которая находится на исходном сервере. Если Request-URI не указывает на существующий ресурс и что URI может быть определен как новый ресурс запрашивающим пользовательским агентом, исходный сервер может создать ресурс с этим URI. Если новый ресурс создан, исходный сервер ДОЛЖЕН информировать пользовательский агент через ответ 201 (создан). Если существующий ресурс изменен, коды @ 200 (OK) или 204 (Нет содержимого) ДОЛЖНЫ быть отправлены, чтобы указать успешное завершение запроса. Если ресурс не может быть создан или изменен с помощью Request-URI, необходимо дать соответствующий ответ об ошибке, который отражает характер проблемы. Получатель объекта НЕ ДОЛЖЕН игнорировать заголовки Content- * (например, Content-Range), которые он не понимает и не реализует, и ДОЛЖЕН вернуть ответ 501 (не реализованный) в таких случаях.

Если запрос проходит через кэш, а Request-URI идентифицирует один или несколько кэшированных объектов в настоящее время, эти записи ДОЛЖНЫ считаться устаревшими. Ответы на этот метод не подлежат кэшированию.

Основное различие между запросами POST и PUT отражается в различном значении Request-URI. POST sorğusundakı URI əlavə olunmuş obyekti idarə edəcək qaynağı müəyyənləşdirir. Этот ресурс может быть процессом принятия данных, шлюзом к другому протоколу или отдельным объектом, который принимает аннотации. Напротив, URI в запросе PUT идентифицирует объект, заключенный с запросом - пользовательский агент знает, что такое URI, и сервер НЕ ДОЛЖЕН пытаться применить запрос к другому ресурсу. Əgər server tələbi fərqli bir URI tətbiq etmək istəyirsə,

301 (köçürülən qalıcı) cavabı göndərməli; пользовательский агент МОЖЕТ затем принять собственное решение относительно перенаправления запроса.

Один ресурс МОЖЕТ быть идентифицирован многими различными URI. Например, статья может иметь URI для идентификации "текущей версии", которая отделена от URI, идентифицирующего каждую конкретную версию. В этом случае запрос PUT на общем URI может привести к тому, что несколько других URI будут определены сервером происхождения.

HTTP/1.1 не определяет, как метод PUT влияет на состояние исходного сервера.

Запросы PUT ДОЛЖНЫ подчиняться требованиям к передаче сообщений, изложенным в разделе 8.2.

Если не указано иное для конкретного заголовка объекта, заголовки сущностей в запросе PUT ДОЛЖНЫ применяться к ресурсу, созданному или измененному PUT.

9.7 УДАЛИТЬ

Метод DELETE запрашивает, чтобы исходный сервер удалял ресурс, идентифицированный Request-URI. Этот метод МОЖЕТ быть переопределен вмешательством человека (или другими средствами) на исходном сервере. Клиент не может гарантировать, что операция выполнена, даже если код состояния, возвращенный с исходного сервера, указывает, что действие выполнено успешно. Тем не менее, сервер НЕ ДОЛЖЕН указывать на успех, если в момент ответа ответа он не захочет удалить ресурс или переместить его в недоступное место.

Успешный ответ ДОЛЖЕН быть 200 (ОК), если ответ включает объект, описывающий статус, 202 (Принято), если действие еще не было принято, или 204 (Нет содержимого), если действие было принято, но ответ не включает объект.

Если запрос проходит через кэш, а Request-URI идентифицирует один или несколько кэшированных объектов в настоящее время, эти записи ДОЛЖНЫ считаться устаревшими. Ответы на этот метод не подлежат кэшированию.

5
ответ дан gahooa 04 янв. '10 в 23:10 2010-01-04 23:10

О кодах возврата REST: неверно , чтобы смешивать коды протокола HTTP и результаты REST.

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

Коды возврата HTTP связаны с самим HTTP Request . Вызов REST выполняется с использованием запроса протокола Hypertext Transfer Protocol и работает на более низком уровне, чем сам метод REST. REST - это концепция/подход, а его вывод - бизнес-логический результат, а HTTP-код результата - транспортный.

Например, если вы вызываете /users/, вы возвращаете "404 Not found", потому что это может означать:

  • URI ошибочен (HTTP)
  • Пользователи не найдены (REST) ​​

"403 Запрещено/Доступ запрещен" может означать:

  • Требуется специальное разрешение. Браузеры могут справиться с этим, попросив пользователя/пароль. (HTTP)
  • Неверные разрешения доступа, настроенные на сервере. (HTTP)
  • Вам необходимо пройти аутентификацию (REST) ​​

И список может продолжаться с ошибкой "500 Server" (ошибка HTTP-атаки Apache/Nginx или ошибка бизнес-ограничения в REST) ​​или другие ошибки HTTP и т.д....

Из кода трудно понять, в чем причина сбоя, сбой HTTP (транспортный) или отказ REST (логический).

Если запрос HTTP физически был успешно выполнен, он должен всегда возвращать код 200, независимо от того, найдена запись или нет. Поскольку ресурс URI найден и обрабатывается сервером http. Bəli, boş bir dəstə dönə bilər. Можно ли получить пустую веб-страницу с 200 в качестве результата http, правильно?

Вместо этого вы можете вернуть 200 HTTP-код и просто JSON с пустым массивом/объектом или использовать флаг bool result/success, чтобы сообщить о выполненном состоянии операции.

Кроме того, некоторые интернет-провайдеры могут перехватывать ваши запросы и возвращать вам 404 http-код. Это не означает, что ваши данные не найдены, но что-то не так на транспортном уровне.

От Wiki :

В июле 2004 года британская телекоммуникационная компания BT Group развернула Cleanfeed система блокирования контента, которая возвращает ошибку 404 для любого запроса для содержание, идентифицированное как потенциально незаконное с помощью Internet Watch Фонд. Другие провайдеры возвращают HTTP 403 "запретную" ошибку в том же обстоятельства. Практика использования поддельных ошибок 404 в качестве средства для в Таиланде и Тунисе также сообщается о скрытой цензуре. В Тунис, где цензура была серьезной до революции 2011 года, люди узнали о природе поддельных ошибок 404 и создали воображаемый персонаж под названием "Аммар 404", который представляет "невидимый цензор".

1
ответ дан Marcodor 23 сент. '17 в 15:08 2017-09-23 15:08

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