REST URI - yaradılan zaman unikal və ya birdən çox resurs adı

REST üçün yeniyim və bəzi RESTful xidmətlərində yenilənmə / qəbul / silmə və yaratmaq üçün müxtəlif resurs URI'larını istifadə etdiyini fərq etdim. Məsələn,

  • Bəzi yerlərdə / resurs (tək) istifadə edərək, POST metodunu (çoxlu sayda müşahidə edin) istifadə edərək / resurslardan yaradın.
  • PUT metodundan istifadə edərək / resurs / 123 istifadə edin
  • Get-istifadə / resurs / 123 GET metodunu istifadə edin

Bu URI adlandırma konvensiyası haqqında bir az qarışıq oldum. Çoxluğun və ya tabanı resurs yaratmaq üçün nə istifadə etməlisiz? Nə qərar verərkən meyarlar nə olmalıdır?

319
27 июля '11 в 17:05 2011-07-27 17:05 JPReddy , 27 İyul 2011 tarixində saat 17: 05- da təyin olunub
@ 16 cavab

/resources istifadəsi üçün ön şərt var ki, "bütün" resursları təmsil edir. GET /resources çalıştırırsanız, çox ehtimal ki bütün kolleksiyanı qaytaracaqsınız. POST-dan /resources kolleksiyaya əlavə edirsiniz.

Lakin, fərdi resurslar / resursda mövcuddur. GET /resource çalıştırırsanız, bu sorğu heç bir məna vermədiyi üçün yanlış olursunuz, buna baxmayaraq /resource/123 mənasını verir.

/resource istifadə edərək, bir fayl sistemi və faylların toplusu ilə işlədiyiniz halda necə işlədiyinizə bənzəyir və /resource birbaşa 123 , 456 olan bir "kataloq" dir.

Yolların heç biri düzgün deyil və ya yanlış deyil, ən yaxşısını istədiyi qədər gedin.

161
27 июля '11 в 17:26 2011-07-27 17:26 cavab iyulun 27-də saat 17: 17-də Will Hartung tərəfindən veriləcək

Əsasən kodun hər iki tərəfində olacağı üçün kodun (avtomatlaşdırıla bilməsi asanlaşdırılacaq) birbaşa əlaqələndirə biləcəyi bir sxem var.

border=0
 GET /orders <---> orders POST /orders <---> orders.push(data) GET /orders/1 <---> orders[1] PUT /orders/1 <---> orders[1] = data GET /orders/1/lines <---> orders[1].lines POST /orders/1/lines <---> orders[1].lines.push(data) 
392
16 февр. Cavab 16 fevralda verilir. 2014-02-16 13:28 '14 saat 13:28 2014-02-16 13:28

Mən də bunun heç bir nöqtəsini görmürəm və bu, ən yaxşı URI dizaynı deyil. RESTful xidmətinin bir istifadəçisi olaraq, siyahıma mənbə siyahısına və ya siyahıda müəyyən bir resursa daxil olub-olmamasından asılı olmayaraq, mənbə resurslarının eyni adda olmasını gözləmək olardı. Bir liste resursunu və ya xüsusi bir resurs istifadə etmək istəməyinizdən asılı olmayaraq, eyni identifikatorlar istifadə etməlisiniz.

203
27 июля '11 в 17:26 2011-07-27 17:26 Cavab Jan Deinhard tərəfindən 27 iyul 'da 17:26' də veriləcək 2011-07-27 17:26

Ən çox yayılmış təcrübə RESTful apis olsa da, məsələn, plurals istifadə olunur. /api/resources/123 , müəyyən bir addan çoxlu addan daha uyğun / ifadəli istifadə etdiyim bir xüsusi vəziyyət var. Bu, bir-bir əlaqələrə aiddir. Xüsusilə, hədəf obyekti dəyər obyektidirsə (domen əsaslı paradiqmada).

Hər bir accessLog obyektin deyil, dəyər obyekti kimi modelləşdirilə bilən accessLog var, belə ki, heç bir identifikator yoxdur. Bu, /api/resources/123/accessLog kimi ifadə edilə bilər. Daimi fiiller (POST, PUT, DELETE, GET) niyyətini ifadə edir, həm də əlaqənin həqiqətən bəxtiyar olmasıdır.

23
07 нояб. Cavab verildi 07 noyabr. 2012-11-07 13:12 '12 at 13:12 2012-11-07 13:12

REST URI-dakı resurs adlandırılması yayılmış standartdır və ictimai və xüsusi API-lərin böyük əksəriyyəti bunu davam etdirir.

"Standart yanaşma" dan başqa, bu da məntiqlidir və ən sadədir.

Məsələn:

GET /resources - qaynaq elementlərinin siyahısını verir

POST /resources - bir və ya daha çox resurs elementi yaradır.

PUT /resources - bir və ya daha çox resurs elementini yeniləyir

PATCH /resources - qismən bir və ya daha çox resurs elementini yeniləyir.

DELETE /resources - DELETE /resources bütün elementlərini rədd edir.

Fərdi resurslar üçün:

GET /resources/:id - parametr əsasında müəyyən bir qaynaq elementi qaytarır :id

POST /resources/:id - müəyyən bir identifikator ilə bir qaynaq elementi yaradır (tələb edin)

PUT /resources/:id - xüsusi bir resurs elementini yeniləyir

PATCH /resources/:id - xüsusi bir resurs elementini qismən yeniləyir.

DELETE /resources/:id - resursun müəyyən bir elementini silə bilər

18
27 авг. Eric Knudtson tərəfindən verilmiş cavab 27 avqust 2015-08-27 21:54 '15 at 21:54 2015-08-27 21:54

donuz

Rahatlıq Düzensiz çoğul adlar ola bilər. Bəzən bunlar yoxdur. Ancaq unikal adlar həmişə mövcuddur.

məsələn. CustomerAddresses üzərində CustomerAddress

Bu əlaqəli qaynağı düşünün.

Bu /order/12/orderdetail/12 daha oxunaqlı və /orders/12/orderdetails/4 daha mantıksaldır /orders/12/orderdetails/4 .

Verilənlər bazası tabloları

Bir qayda verilənlər bazası cədvəlinə bənzər bir obyektdir. Mantıksız tək adı olmalıdır. Masa adları üçün cavabdır .

Sinif Xəritəçəkmə

Dərslər həmişə təkdir. ORM alətləri sinif adları ilə eyni adlarla masalar yaradır. Daha çox vasitə istifadə edildikdə, unikal adlar standart olur.

REST API İstehsalçı Dilemma haqqında daha ətraflı oxuyun

16
20 нояб. Cavab sıralayan noyabr 20 2015-11-20 13:13 '15 'da 13:13' də dəyişiklik edildi

Niyə tək bir forma adətən qəbul edilən verilənlər bazası masalarının adlarının ümumi tendensiyasını izləmək olmaz? Orada olubmu?

Cədvəlin adları dilemma: tək və ya çoğul adlar

14
11 янв. Cavab 11 yanvar Debriter tərəfindən verilir 2014-01-11 21:47 '14 da 21:47 2014-01-11 21:47

İstehlakçı baxımından, API-nın son nöqtələri öngörülənə bilməsi lazımdır

İdeal olaraq ...

  • GET /resources siyahısını qaytarmalıdır.
  • GET /resource səviyyəsi 400 status kodunu qaytarmalıdır.
  • GET /resources/id/{resourceId} toplusu bir qayda ilə geri qaytarmalıdır.
  • GET /resource/id/{resourceId} bir qaynaq obyekti qaytarmalıdır.
  • POST /resources paket resursları olmalıdır.
  • POST /resource yaratmalıdır.
  • PUT /resource resurs obyektini yeniləməlidir.
  • PATCH /resource yalnız dəyişdirilmiş atributları dərc edərək resursu yeniləməlidir.
  • PATCH /resources , yalnız dəyişdirilmiş atributları göndərən resursları topluca yeniləməlidir.
  • DELETE /resources bütün resursları silməlidir; yalnız bir zarafat: status kodu 400
  • DELETE /resource/id/{resourceId}

Bu yanaşma ən çevik və çoxfunksiyalı, eyni zamanda inkişaf etmək üçün ən çox vaxt aparan bir sistemdir. Beləliklə, tələsik olsanız (proqram inkişafı ilə həmişə olduğu kimi), son nöqtə resource və ya çoxsaylı form resources sadəcə baxın. Mən vahid formanı seçirəm, çünki bütün introspektiv şəkildə qiymətləndirmək və qiymətləndirmək üçün imkan verir, çünki bütün çoxlu formalar 's' ilə bitmir.

Bütün bunları söyləyərək, hər hansı bir səbəbdən, ən çox istifadə edilən təcrübənin inkişaf etdiricisi bir çoxluq formasını istifadə etməyi seçir. Bu, nəhayət, mən seçdiyim marşrutdur və əgər githubtwitter kimi məşhur apisə baxırsınızsa, bunlar github .

Qərarın bəzi meyarları ola bilər:

  • Vaxtım nədir?
  • İstifadəçilərimə hansı əməliyyatları etməyə icazə verəcəyəm?
  • Sorgu və nəticə nə görünür?
  • Mənim kodumda URI-ləri əks etdirmək və təhlil etmək istərdim?

Beləliklə, bu sizin üçündür. Yalnız razılaşdığınız hər şey.

10
20 июня '15 в 2:17 2015-06-20 02:17 cosbor11 cavab 20 iyun, '15 də 2:17 'də verilir 2015-06-20 02:17

Mən plüralist isimdə çox adamın atlayışını görməkdən şadam. Bir çox dəyişikliyə tək bir nömrə gətirərkən, qeyri-qanuni çoxlu isim tətbiq edirsiniz? Acıyı sevirsən?

Http://web2.uvcs.uvic.ca/elc/studyzone/330/grammar/irrplu.htm səhifəsinə baxın .

Düzensiz plurals bir çox növü var, lakin onlar ən ümumi:

Noun növü Plural forma nümunəsi

F-v dəyişikliyinə son qoyur sonra arvadın həyatının bıçaq ömrü üçün bıçaq əlavə edin -f Change to f sonra v yarım yarım qurd canavar çörək əlavə edin -o Add-kartof kartof pomidol vulkan vulkanları ilə bitir Change -us-i-kaktus kernel əsas kaktus diqqət təhlili təhlili diqqət mərkəzindədir -is dəyişikliklər-böhran böhranları dissertasiya tezisləri sona çatdıqda-dəyişmək -bir-fenomen meyarının meyarı BÜTÜN TYPES səsyazma dəyişikliyi və ya dəyişdirmək sözü və ya əlavə et kişilər üçün başqa bir kişi ayaq körpə uşaqlar uşaqlar kişi diş dişləri siçan siçanları sınırsız tək və çoxluq eyni qoyun və ya geyik balığı (bəzən)

4
02 марта '17 в 21:16 2017-03-02 21:16 Stephan Erickson tərəfindən cavab 02.03 ' da 21:16 2017-03-02 21:16

Adlandırma konvensiyaları ilə, adətən "yalnız birini seçin və qalmaq" deyən təhlükəsizdir, bu mənada.

Ancaq, fayl sistemində yol kimi son nöqtələri təmsil edən çox sayda insana REST izah edildikdən sonra bunu etmənin ən ifadəli üsuludur. Bu, əsassızdır (fayllar mövcuddur və ya mövcud deyil), hiyerarşik, sadə və tanışdır - yerli olaraq və ya http vasitəsilə statik fayllara necə giriş əldə edə bilirsiniz.

Və bu məzmunda linqvistik qaydalar yalnız aşağıdakılara gətirib çıxara bilər:

Bir qovluq bir neçə fayl və / və ya alt dizin ola bilər, belə ki, adı çoxluqdə olmalıdır.

Və mən bunu sevirəm.
Digər tərəfdən bu sizin diziniz olsa da, istədiyiniz bir şey varsa, "resurs-ya-bir neçə resurs" deyə bilərsiniz. Bu çox əhəmiyyətli bir şey deyil.

Əhəmiyyətli olan ki, "resourceS" qovluğunda "123" adlı bir fayl qoyduğunuzda (nəticənin /resourceS/123 ), /resource/123 vasitəsilə əldə olmasını gözləmək olmaz.

Lazım olduğundan daha ağıllı olmaq üçün çalışmayın - hal-hazırda istinad etdiyiniz resursların sayından asılı olaraq çoxluğa keçid estetikaya xoş ola bilər, lakin effektiv deyil və hiyerarxik bir sistemdə mənalı deyil .

Qeyd Texniki olaraq, "simvolik bağlantılar" yarada bilərsiniz, beləliklə /resourceS/123 vasitəsilə əldə oluna bilər, amma birincisi mövcud olmalıdır!

3
25 марта '16 в 19:37 2016-03-25 19:37 Cavab Narf 25 mart '16, 19:37 2016-03-25 19:37 'də verilir

Mənim iki qəpik: vaxtlarını çoxluqdan təkrarlı və ya əksinə hərəkət edən metodlar prosessor dövrünün bir sərfidir. Mən köhnə bir məktəb ola bilərəm amma bir anda, hər şey kimi, eyni şeyi dedilər. İnsanlarla əlaqəli üsulları necə axtarmaq lazımdır? Heç bir müntəzəm ifadə həm də bir şəxsin və insanların istənməyən yan təsirləri olmadan əhatə etməyəcəkdir.

İngiltərədəki çoğullar çox qüsursuz ola bilərlər və kodunu yükləməzlər. Bir adlandırma konvensiyasına toxun. Kompüter dilinin riyazi aydınlığa sahib olacağı və təbii dil simulyasiya etməyəcəyi ehtimal edilmişdir.

3
18 авг. cavab verdi Guichito 18 aug. 2015-08-18 21:54 '15 'da saat 21:54' de

Sadəlik və uyğunluq üçün tək formadan istifadə etməyi üstün edirəm.

Məsələn, aşağıdakı URL verilir:

/ müştəri / 1

Müştərilərə müştərilərin toplusu kimi baxacağam, lakin sadəlik üçün prefab hissəsi silinir.

Digər bir nümunə:

/ avadanlıq / 1

Bu halda avadanlıq düzgün çoğul form deyil. Buna görə, avadanlıqların montajı və toplanmanın sadəliyə gətirilməsi kimi nəzərə alınmaqla, müştərinin vəziyyətinə uyğun gəlir.

2
05 сент. Cavab verilir ivxivx 05 sentyabr . 2016-09-05 05:26 '16 saat 05:26 'da 2016-09-05 05:26

Bütün metodlar üçün çoxlu istifadə edərək daha az praktikdir, ən azı bir aspektdə: Postman (və ya oxşar alət) istifadə edərək, resurs API-lərini hazırlasanız və test etsəniz, GET-dən PUT-ə POST-ə keçiddə URI-i redaktə etməliyəm.

1
10 авг. Cavab Paulo Merson 10 avqustda verilir. 2016-08-10 16:41 '16 saat 16:41 'da 2016-08-10 16:41

Hər iki təqdimat faydalıdır. Bir müddət rahatlıq üçün yeganə istifadə edirəm, əyilmə çətin ola bilər. Həqiqətən xüsusi REST API-lərin inkişafında mənim təcrübəm, son nöqtəni istehlak edən inkişafçılar, nəticənin forması nə olacağına inamın olmaması. İndi cavab formasını ən yaxşı təsvir edən termini istifadə etməyi üstün edirəm.

Bütün qaynaqlarınız yüksək səviyyədədirsə, tək təsdiqi ilə uzaqlaşa bilərsiniz. Qığılcımdan çəkinin böyük bir qazancdır.

Əlaqələr üçün istəkləri təqdim etmək üçün hər hansı bir dərin bağlama etsəniz, API yazan developers daha sərt bir müqavilə ilə kömək edə bilər.

Mənim konvensiyam ki, bir URI-da hər bir dərinlik səviyyəsi ana qayda ilə qarşılıqlı təsirləri təsvir edir və tam URI dərhal qəbul edilənləri təsvir etməlidir.

Düşünürük ki, bizdə aşağıdakı model var.

 interface User { <string>id; <Friend[]>friends; <Manager>user; } interface Friend { <string>id; <User>user; ...<<friendship specific props>> } 

Bir müştərinin müəyyən bir istifadəçi üçün müəyyən bir dostun meneceri əldə etməyə imkan verən bir qaynaq təmin etməsi lazım olsa, belə bir şeyə baxa bilər:

GET /users/{id}/friends/{friendId}/manager

Aşağıdakılar nümunələrdir:

  • GET /users - qlobal istifadəçi kolleksiyasındakı istifadəçi resurslarının siyahısı
  • POST /users - qlobal istifadəçi kolleksiyasında yeni bir istifadəçi yaratmaq
  • GET /users/{id} - qlobal istifadəçi kolleksiyasından xüsusi istifadəçi almaq
  • GET /users/{id}/manager - müəyyən bir istifadəçi menecerini əldə edin
  • GET /users/{id}/friends - istifadəçi dostlarının siyahısını əldə edin
  • GET /users/{id}/friends/{friendId} - istifadəçinin müəyyən bir dostu olsun
  • LINK /users/{id}/friends - bu istifadəçiyə dostlar birliyini əlavə edin
  • UNLINK /users/{id}/friends - bu istifadəçidən dostların birliyini sil

Hər səviyyədə təsirə məruz qalan ana ilə necə uyğun olduğuna diqqət yetirin. Eyni obyekt üçün müxtəlif valideynlərdən istifadə etmək məntiqsizdir. GET /resource/123 də bir resurs çıxarmaq POST /resources yeni bir resurs yaradılmasının lazım olduğunu göstərmir

1
14 июня '17 в 23:54 2017-06-14 23:54 Cavab Steve Buzonas tərəfindən 14 İyun '17 'də 11:54 2017-06-14 23:54' də verilir

Mən çoxlu ( /resources ) və təkli ( /resource/{id} ) istifadə etməyi üstün tuturam, çünki məncə məntiqi resursları toplamaq və bir qayda üzrə işləməylə işi daha aydın şəkildə ayırır.

Bunun mühüm yan təsiri kimi, API-nin sui-istifadəsinin qarşısını almağa kömək edə bilər. Məsələn, bir istifadəçi yanlışlıkla Id'yi bir parametre olaraq aşağıdakı kimi belirterek bir kaynak elde etmeye çalıştığı halda düşünün:

 GET /resources?Id=123 

Bu halda, birdən çox versiyanı istifadə edərkən, server ən çox ehtimal Id parametrini görmür və bütün resursların siyahısını verir. İstifadəçi diqqətli olmadıqda, zəngin müvəffəqiyyətli olduğunu düşünür və siyahıda ilk resurs istifadə edir.

Digər tərəfdən, tək formadan istifadə edərkən:

 GET /resource?Id=123 

identifikatorun düzgün göstərilməməsi və istifadəçinin bir şeyin yanlış olduğunu başa düşmək məcburiyyətində qalması səbəbindən server çox güman ki, bir səhv qaytarır.

0
01 дек. Peter Berggreen tərəfindən verilmiş cavab 01 Dek 2017-12-01 13:32 '17 də 13:32 'də 2017-12-01 13:32' də

Yalnız elementlər elementi nəzarət edərkən, çarpanlar kolleksiyanı manipulyasiya edirlər. bu kolleksiya daxilində.

Toplama, GET / POST / DELETE metodlarını istifadə etməyə imkan verir

Element, GET / PUT / DELETE üsullarını istifadə etməyə imkan verir

Məsələn,

/ Cart_items haqqında DELETE səbətdə bütün maddələr silinəcəkdir .

/ Cart_item / 123 ünvanında DELETE, geri dönüşüm qutusundan 123 siləcək .

Bu əhəmiyyətsiz görünə bilər, amma bəzi mühəndislər bəzən identifikatoru unuturlar. Marşrut həmişə çoxluysa və DELETE yerinə yetirilmişsə, siz təsadüfən məlumatlarınızı silə bilərsiniz. Tekil tanıdıcı eksikse, tapılmayan bir 404 yolunu qaytarır.

0
27 февр. Cavab 27 fevral fəlakət verilir . 2017-02-27 04:10 '17 at 4:10 2017-02-27 04:10