RESTful programlama tam olarak nedir?


Al─▒nan cevaba git


RESTful programlama tam olarak nedir?


3904









Cevap say─▒s─▒n─▒ say: 30






Bir mimari tarz─▒ denilen D─░NLENME (rest) o gibi bu web uygulamalar─▒, HTTP kullanmal─▒d─▒r savunan aslen ├Âng├Âr├╝len . Aramalar GET istekleri kullanmal─▒d─▒r . PUT , POST Ve DELETE istekler i├žin kullan─▒lmal─▒d─▒r s─▒ras─▒yla mutasyon, yarat─▒l─▒┼č ve silme .

REST taraftarlar─▒, URLÔÇÖleri, ├Ârne─čin

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

ancak REST mimarisi bu "g├╝zel URL'leri" gerektirmez. Parametreli bir GET iste─či

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

RESTful olarak her bit.

GET isteklerinin hi├žbir zaman bilgileri g├╝ncellemek i├žin kullan─▒lmamas─▒ gerekti─čini unutmay─▒n. ├ľrne─čin, bir sepete bir ├Â─če eklemek i├žin GET iste─či

 http://myserver.com/addToCart?cart=314159&item=1729
 

uygun olmazd─▒. GET istekleri ├Ânemsiz olmal─▒d─▒r . Ba┼čka bir deyi┼čle, bir talebi iki kez vermek, bir kez vermekten farkl─▒ olmamal─▒d─▒r. Talepleri ├Ânbelleklenebilir yapan ┼čey budur. Bir "sepete ekle" iste─či ├Ânemsiz de─čildir; iki kez yay─▒nlanmas─▒, ├╝r├╝n├╝n iki kopyas─▒n─▒ sepete ekler. Bir POST iste─či bu ba─člamda a├ž─▒k├ža uygundur. Bu nedenle, bir RESTful web uygulamas─▒ bile POST isteklerinden pay─▒na ihtiya├ž duyuyor.

Bu, Core JavaServer'─▒n m├╝kemmel kitab─▒ David M. Geary'nin kitab─▒ndan al─▒nm─▒┼čt─▒r.


702







REST , web'in temelindeki mimari prensiptir. Web ile ilgili ┼ča┼č─▒rt─▒c─▒ olan ┼čey, istemcilerin (taray─▒c─▒lar─▒n) ve sunucular─▒n, sunucu ve bar─▒nd─▒rd─▒─č─▒ kaynaklar hakk─▒nda ├Ânceden bir ┼čey bilmeden karma┼č─▒k ┼čekillerde etkile┼čime girebilmesidir. Temel k─▒s─▒tlama, hem sunucunun hem de istemcinin , web durumunda HTML olan kullan─▒lan medya ├╝zerinde hemfikir olmas─▒ gerekti─čidir .

REST ilkelerine uygun bir API , m├╝┼čteriden API'nin yap─▒s─▒ hakk─▒nda bir ┼čey bilmesini gerektirmez. Aksine, sunucunun m├╝┼čteriyle hizmetle etkile┼čime girmesi i├žin gereken bilgileri sa─člamas─▒ gerekir. Bir HTML formu buna bir ├Ârnektir: Sunucu kayna─č─▒n konumunu ve gerekli alanlar─▒ belirtir. Taray─▒c─▒, bilgilerin nereye g├Ânderilece─čini ├Ânceden bilmez ve hangi bilgilerin g├Ânderilece─čini ├Ânceden bilmez. Her iki bilgi t├╝r├╝ de tamamen sunucu taraf─▒ndan sa─član─▒r. (Bu ilkeye HATEOAS : Uygulama Durumunun Motoru Olarak Hypermedia denir .)

Peki, bu HTTP i├žin nas─▒l ge├žerlidir ve pratikte nas─▒l uygulanabilir? HTTP, fiiller ve kaynaklar etraf─▒nda y├Ânlendirilir. Yayg─▒n kullan─▒mdaki iki fiil GET ve POST herkesin tan─▒yaca─č─▒n─▒ d├╝┼č├╝n├╝yorum. Bununla birlikte, HTTP standard─▒ PUT ve gibi baz─▒ di─čerlerini tan─▒mlar DELETE . Bu fiiller daha sonra sunucu taraf─▒ndan verilen talimatlara g├Âre kaynaklara uygulan─▒r.

├ľrne─čin, bir web servisi taraf─▒ndan y├Ânetilen bir kullan─▒c─▒ veritaban─▒m─▒z oldu─čunu d├╝┼č├╝nelim. Hizmetimiz, JSON'a dayanan ve bunun i├žin mimetipi atad─▒─č─▒m─▒z ├Âzel bir hiper medya kullan─▒yor. application/json+userdb (Ayr─▒ca application/xml+userdb ve application/whatever+userdb bir├žok medya t├╝r├╝ de desteklenebilir). ─░stemci ve sunucu bu format─▒ anlayacak ┼čekilde programlanm─▒┼čt─▒r, ancak birbirleri hakk─▒nda hi├žbir ┼čey bilmezler. Roy Fielding'in dedi─či gibi :

Bir REST API, kaynak g├Âstermek ve uygulama durumunu belirtmek i├žin kullan─▒lan ortam t├╝rlerini tan─▒mlamak veya mevcut standart ortam t├╝rleri i├žin geni┼čletilmi┼č ili┼čki adlar─▒ ve / veya k├Âpr├╝ metni etkin marketi tan─▒mlamak i├žin tan─▒mlay─▒c─▒ ├žabas─▒n─▒n neredeyse tamam─▒n─▒ harcamal─▒d─▒r.

Temel kaynak i├žin bir istek / ┼č├Âyle bir ┼čey d├Ând├╝rebilir:

─░stek

 GET /
Accept: application/json+userdb
 

Tepki

 200 OK
Content-Type: application/json+userdb

{
    "version": "1.0",
    "links": [
        {
            "href": "/user",
            "rel": "list",
            "method": "GET"
        },
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}
 

Medya a├ž─▒klamas─▒ndan kaynaklarla ilgili bilgileri "ba─člant─▒lar" b├Âl├╝mlerinden bulabilece─čimizi biliyoruz. Buna Hypermedia kontrolleri denir . Bu durumda, b├Âyle bir b├Âl├╝mden ba┼čka bir istek yaparak bir kullan─▒c─▒ listesi bulabilece─čimizi s├Âyleyebiliriz /user :

─░stek

 GET /user
Accept: application/json+userdb
 

Tepki

 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"
        }
    ]
}
 

Bu cevaptan ├žok ┼čey s├Âyleyebiliriz. ├ľrne─čin, ┼ču noktalara POST giderek yeni bir kullan─▒c─▒ olu┼čturabilece─čimizi biliyoruz /user :

─░stek

 POST /user
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Karl",
    "country": "Austria"
}
 

Tepki

 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"
    }
}
 

Ayr─▒ca mevcut verileri de─či┼čtirebilece─čimizi de biliyoruz:

─░stek

 PUT /user/1
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Emil",
    "country": "Bhutan"
}
 

Tepki

 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"
    }
}
 

Farkl─▒ HTTP fiilleri kulland─▒─č─▒n─▒z─▒ Bildirimi ( GET , PUT , POST , DELETE vb) bu kaynaklar─▒ i┼člemek ve biz m├╝┼čterinin k─▒sm─▒nda tahmin sadece bilgi bizim medya tan─▒m─▒ oldu─čunu i├žin.

Daha fazla okuma:

(Bu cevap, noktay─▒ ka├ž─▒rmak i├žin adil bir ele┼čtiriye konu olmu┼čtur. ├ço─ču zaman, bu adil bir ele┼čtiri olmu┼čtur. ─░lk olarak tarif etti─čim ┼čey, REST'in genellikle birka├ž y─▒l ├Ânce ne zaman uygulan─▒rken uyguland─▒─č─▒ ile ayn─▒yd─▒. ├Ânce ger├žek anlam─▒ndan ziyade bunu yazd─▒m. As─▒l anlam─▒ daha iyi temsil etmek i├žin cevab─▒ revize ettim.)


2896







RESTful programlama hakk─▒nda:

  • kal─▒c─▒ bir tan─▒mlay─▒c─▒ taraf─▒ndan tan─▒mlanan kaynaklar: URI'lar bug├╝nlerde her yerde bulunan tan─▒mlay─▒c─▒ tercihidir.
  • kaynaklar fiiller ortak seti kullan─▒larak manip├╝le ediliyor: HTTP y├Ântemleri s─▒kl─▒kla g├Âr├╝len harfe - sayg─▒de─čer Create , Retrieve , Update , Delete olur POST , GET , PUT , ve DELETE . Ancak REST, HTTP ile s─▒n─▒rl─▒ de─čildir, ┼ču anda en yayg─▒n kullan─▒lan ula┼č─▒m arac─▒d─▒r.
  • Bir kaynak i├žin al─▒nan ger├žek g├Âsterim, tan─▒mlay─▒c─▒ya de─čil talebe ba─čl─▒d─▒r: XML, HTTP veya hatta kayna─č─▒ temsil eden bir Java Nesnesi isteyip istemedi─činizi kontrol etmek i├žin Kabul ba┼čl─▒klar─▒n─▒ kullan─▒n
  • devletin nesnede tutulmas─▒ ve devletin temsilde temsil edilmesi
  • Kaynak g├Âsterimi i├žindeki kaynaklar aras─▒ndaki ili┼čkileri temsil eder: Nesneler aras─▒ndaki ba─člant─▒lar do─črudan g├Âsterime dahil edilir.
  • kaynak g├Âsterimleri, g├Âsterimin nas─▒l kullan─▒labilece─čini ve hangi ┼čartlar alt─▒nda tutarl─▒ bir ┼čekilde at─▒lmas─▒ / tekrar kullan─▒lmas─▒ gerekti─čini tan─▒mlar: HTTP ├ľnbellek Kontrol├╝ ba┼čl─▒klar─▒n─▒n kullan─▒m─▒

Sonuncusu, REST'in sonu├žlar─▒ ve genel etkinli─či a├ž─▒s─▒ndan muhtemelen en ├Ânemlisidir. Genel olarak, RESTful tart─▒┼čmalar─▒n─▒n ├žo─ču, HTTP'ye ve bunun bir taray─▒c─▒daki kullan─▒m─▒na odaklan─▒yor gibi g├Âr├╝nmektedir. R. Fielding'in mimariyi ve HTTP'ye yol a├žan kararlar─▒ tarif ederken terimi belirtti─čini anl─▒yorum. Tezi, kaynaklar─▒n mimarisi ve ├Ânbellek yetene─či hakk─▒nda HTTP'dekinden daha fazla.

E─čer RESTful bir mimarinin ne oldu─ču ve neden ├žal─▒┼čt─▒─č─▒yla ger├žekten ilgileniyorsan─▒z , tezini birka├ž kez okuyun ve sadece B├Âl├╝m 5'i de─čil her ┼čeyi okuyun ! DNS'nin neden ├žal─▒┼čt─▒─č─▒na bir sonraki bak─▒┼č . DNS'in hiyerar┼čik organizasyonu ve y├Ânlendirmelerin nas─▒l ├žal─▒┼čt─▒─č─▒n─▒ okuyun. Ard─▒ndan, DNS ├Ânbelle─činin nas─▒l ├žal─▒┼čt─▒─č─▒n─▒ okuyun ve d├╝┼č├╝n├╝n. Son olarak, HTTP spesifikasyonlar─▒n─▒ (├Âzellikle RFC2616 ve RFC3040 ) okuyun ve ├Ânbelleklemenin nas─▒l ├žal─▒┼čt─▒─č─▒n─▒ nas─▒l ve neden yapt─▒─č─▒n─▒ g├Âz ├Ân├╝nde bulundurun. Sonunda, sadece t─▒klayacakt─▒r. Benim i├žin son vahiy, DNS ile HTTP aras─▒ndaki benzerli─či g├Ârd├╝─č├╝mde oldu. Bundan sonra, SOA ve ─░leti ─░letme Arabirimlerinin neden ├Âl├žeklenebildi─čini anlamak t─▒klamaya ba┼člar.

RESTful ve Payla┼č─▒lan Hi├žbir ┼×ey mimarisinin mimari ├Ânemini ve performans etkilerini anlamadaki en ├Ânemli numara , teknolojiye ve uygulama detaylar─▒na dokunulmaktan ka├ž─▒nmak oldu─čunu d├╝┼č├╝n├╝yorum. Kaynaklara kimin sahip oldu─čuna, onlar─▒ olu┼čturmaktan / s├╝rd├╝rmekten sorumlu olana vb. Odaklan─▒n. Sonra sunumlar─▒, protokolleri ve teknolojileri d├╝┼č├╝n├╝n.


527







G├Âr├╝nd├╝─č├╝ gibi.

├ť├ž ├Âzelli─če sahip bir kullan─▒c─▒ olu┼čturun:

 POST /user
fname=John&lname=Doe&age=25
 

Sunucu yan─▒t verir:

 200 OK
Location: /user/123
 

Gelecekte, kullan─▒c─▒ bilgisini alabilirsiniz:

 GET /user/123
 

Sunucu yan─▒t verir:

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

Kayd─▒ de─či┼čtirmek i├žin ( lname ve age de─či┼čmeden kalacakt─▒r):

 PATCH /user/123
fname=Johnny
 

Kayd─▒n─▒ g├╝ncellemek i├žin (ve dolay─▒s─▒yla lname ve age NULL olacakt─▒r):

 PUT /user/123
fname=Johnny
 

405







REST ├╝zerine harika bir kitap, Pratikte REST'dir .

Zorunluluk okur vard─▒r rest (D─░NLENME) ve REST API'leri k├Âpr├╝ odakl─▒ olmal─▒d─▒r

RESTful hizmetinin ne oldu─čuna dair bir a├ž─▒klama i├žin , bkz. Martin Fowlers makalesi Richardson Olgunluk Modeli (RMM).


Richardson Olgunluk Modeli

RESTful olmak i├žin bir Hizmetin Uygulama Durumunun Motoru olarak Hypermedia'y─▒ yerine getirmesi gerekir . (HATEOAS) , yani, RMM'deki 3. seviyeye ula┼čmas─▒, ayr─▒nt─▒lar i├žin makaleyi veya qcon konu┼čmas─▒ndan slaytlar─▒ okumas─▒ gerekir .

HATEOAS k─▒s─▒tlamas─▒, Uygulama Durumunun Motoru olarak Hypermedia i├žin bir k─▒saltmad─▒r. Bu ilke, bir REST ve di─čer bir├žok istemci sunucu sistemi formlar─▒ aras─▒ndaki anahtar fark edicidir.

...

RESTful bir uygulaman─▒n m├╝┼čterisinin, eri┼čmek i├žin yaln─▒zca tek bir sabit URL bilmesi gerekir. Gelecekteki t├╝m eylemler, s├Âz konusu URLÔÇÖden d├Ând├╝r├╝len kaynaklar─▒n temsillerinde bulunan hypermedia ba─člant─▒lar─▒ndan dinamik olarak ke┼čfedilmelidir. Standardize edilmi┼č medya t├╝rlerinin de bir RESTful API kullanabilecek herhangi bir m├╝┼čteri taraf─▒ndan anla┼č─▒lmas─▒ beklenmektedir. (Vikipedi, ├Âzg├╝r ansiklopedi)

Web ├çer├ževeleri i├žin REST Litmus Testi, web ├žer├ževeleri i├žin benzer bir vade testidir.

Saf REST'e yakla┼čmak: HATEOAS'─▒ sevmeyi ├Â─črenmek , iyi bir ba─člant─▒ derlemesidir.

Public Cloud i├žin SOAP'a kar┼č─▒ REST , ge├žerli REST kullan─▒m d├╝zeylerini tart─▒┼č─▒r.

REST ve s├╝r├╝m olu┼čturma, De─či┼čtirilebilirlik ile Geni┼čletilebilirlik, S├╝r├╝m Olu┼čturma, Geli┼čtirilebilirlik, vb.


179







REST nedir?

REST, Temsili Devlet Transferi anlam─▒na gelir. (Bazen "ReST" yaz─▒l─▒r.) Vatans─▒z, istemci-sunucu, ├Ânbellek ileti┼čim protokol├╝ne dayan─▒r - ve hemen hemen her durumda, HTTP protokol├╝ kullan─▒l─▒r.

REST, a─č uygulamalar─▒ olu┼čturmak i├žin kullan─▒lan bir mimari tarzd─▒r. Fikir, makineler aras─▒nda ba─člant─▒ kurmak i├žin CORBA, RPC veya SOAP gibi karma┼č─▒k mekanizmalar kullanmak yerine, makineler aras─▒nda ├ža─čr─▒ yapmak i├žin basit HTTP'nin kullan─▒lmas─▒d─▒r.

Bir├žok y├Ânden, HTTP'ye dayanan World Wide Web'in kendisi REST tabanl─▒ bir mimari olarak g├Âr├╝lebilir. RESTful uygulamalar veri g├Ândermek (olu┼čturmak ve / veya g├╝ncellemek), verileri okumak (├Ârne─čin, sorgu yapmak) ve verileri silmek i├žin HTTP isteklerini kullan─▒r. Bu nedenle, REST d├Ârt CRUD (Olu┼čtur / Oku / G├╝ncelle / Sil) i┼čleminin t├╝m├╝ i├žin HTTP kullan─▒r.

REST, RPC (Uzaktan Prosed├╝r ├ça─čr─▒lar─▒) ve Web Servisleri (SOAP, WSDL, vd.) Gibi mekanizmalara hafif bir alternatiftir. Daha sonra, REST'in ne kadar basit oldu─čunu g├Ârece─čiz.

Basit olmas─▒na ra─čmen, REST tam ├Âzellikli; Temelde Web Servislerinde yapabilece─činiz hi├žbir ┼čey RESTful mimarisi ile yap─▒lamaz. REST "standart" de─čildir. ├ľrne─čin, REST i├žin asla bir W3C ├Ânerisi olmayacak. Ve REST programlama ├žer├ževeleri varken, REST ile ├žal─▒┼čmak o kadar basittir ki Perl, Java veya C # gibi dillerde standart k├╝t├╝phane ├Âzellikleriyle s─▒k s─▒k "kendinize" atabilirsiniz.

Dinlenmenin basit ger├žek anlam─▒n─▒ bulmaya ├žal─▒┼č─▒rken buldu─čum en iyi referanslardan biri.

http://rest.elkstein.org/


133


2012-11-18





REST, verileri i┼člemek i├žin ├že┼čitli HTTP y├Ântemlerini (├žo─čunlukla GET / PUT / DELETE) kullan─▒yor.

Bir y├Ântemi silmek i├žin belirli bir URL kullanmak yerine (diyelim /user/123/delete ), /user/[id] bir GET iste─či g├Ânderdi─činiz bir kullan─▒c─▒ hakk─▒nda bilgi almak i├žin bir kullan─▒c─▒y─▒ d├╝zenlemek , URL'ye bir S─░LME iste─či g├Ânderirsiniz. /user/[id]

├ľrne─čin, bunun yerine, a┼ča─č─▒dakilerden baz─▒lar─▒na benzeyebilecek bir URL k├╝mesi ..

 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 "fiilleri" kullan─▒yorsunuz ve ..

 GET /user/2
DELETE /user/2
PUT /user
 

88


2009-03-22





Sisteminizin mimarisinin Roy Fielding'in tezinde ortaya koydu─ču REST stiline uydu─ču programlama . Bu, web'i (az ya da ├žok) tan─▒mlayan mimari tarz oldu─čundan, pek ├žok insan onunla ilgilenmektedir.http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

Bonus cevap: Hay─▒r. Yaz─▒l─▒m mimarisini akademik olarak ya da web tasar─▒m─▒ tasarlarken okumad─▒─č─▒n─▒z s├╝rece, bu terimi duymak i├žin hi├žbir neden yoktur.


68







RESTful programlaman─▒n, REST mimari tarz─▒n─▒ takip eden sistemler (API) olu┼čturmakla ilgili olaca─č─▒n─▒ s├Âyleyebilirim.

Dr. Elkstein'─▒n REST hakk─▒ndaki ├Â─čreticisini anlatan bu k─▒sa, k─▒sa ve anla┼č─▒lmas─▒ kolay buldum ve sorunuzun ├žo─čuna cevap verecek olan ├Ânemli k─▒sm─▒ al─▒nt─▒:

REST ├ľ─čren: Bir ├ľ─čretici

REST, a─č uygulamalar─▒ olu┼čturmak i├žin kullan─▒lan bir mimari tarzd─▒r . Fikir, makineler aras─▒nda ba─člant─▒ kurmak i├žin CORBA, RPC veya SOAP gibi karma┼č─▒k mekanizmalar kullanmak yerine, makineler aras─▒nda ├ža─čr─▒ yapmak i├žin basit HTTP'nin kullan─▒lmas─▒d─▒r.

  • Bir├žok y├Ânden, HTTP'ye dayanan World Wide Web'in kendisi REST tabanl─▒ bir mimari olarak g├Âr├╝lebilir.

RESTful uygulamalar veri g├Ândermek (olu┼čturmak ve / veya g├╝ncellemek), verileri okumak (├Ârne─čin, sorgu yapmak) ve verileri silmek i├žin HTTP isteklerini kullan─▒r. Bu nedenle, REST d├Ârt CRUD (Olu┼čtur / Oku / G├╝ncelle / Sil) i┼čleminin t├╝m├╝ i├žin HTTP kullan─▒r.

Y─▒─č─▒n Ta┼čmas─▒ d─▒┼č─▒nda REST hakk─▒nda bir ┼čeyler duymad─▒─č─▒n─▒z i├žin aptal hissetmemelisiniz bence ... ayn─▒ durumda olurum! Bu di─čer SO sorusunun cevab─▒ ise REST neden b├╝y├╝yor ┼čimdi baz─▒ duygular─▒ kolayla┼čt─▒rabilir.


47







Soruyu do─črudan cevaplam─▒yorsam ├Âz├╝r dilerim, ancak t├╝m bunlar─▒ daha ayr─▒nt─▒l─▒ ├Ârneklerle anlamak daha kolay. Fielding, t├╝m soyutlamalar ve terminoloji nedeniyle anla┼č─▒lmas─▒ kolay de─čildir.

Burada olduk├ža iyi bir ├Ârnek var:

REST ve K├Âpr├╝ Metnini A├ž─▒klamak: Spam-E Spam Temizleme Robotu

Ve daha da iyisi, burada basit ├Ârneklerle temiz bir a├ž─▒klama var (powerpoint daha kapsaml─▒, ancak ├žo─čunu html versiyonunda bulabilirsiniz):

http://www.xfront.com/REST.ppt veya http://www.xfront.com/REST.html

├ľrnekleri okuduktan sonra, Ken'in neden REST'in k├Âpr├╝ metni taraf─▒ndan y├Ânlendirildi─čini s├Âyledi─čini anlayabiliyorum. Ger├žekten de hakl─▒ oldu─čundan emin de─čilim, ├ž├╝nk├╝ / user / 123 bir kayna─ča i┼čaret eden bir URI'dir ve yaln─▒zca m├╝┼čterinin "bant d─▒┼č─▒" oldu─čunu bilmesi nedeniyle bana kar┼č─▒ konulmad─▒─č─▒ a├ž─▒k de─čildir.

Bu xfront belgesi REST ve SOAP aras─▒ndaki fark─▒ a├ž─▒kl─▒yor ve bu da ger├žekten yard─▒mc─▒ oluyor. Fielding, " Bu, RPC. RPC'yi hayk─▒r─▒yor. " Derken, RPC'nin RESTful olmad─▒─č─▒ a├ž─▒k, bu y├╝zden bunun kesin nedenlerini g├Ârmek faydal─▒. (SOAP bir RPC t├╝r├╝d├╝r.)


45







REST nedir?

Resmi kelimelerle REST, REST, g├╝ncel ÔÇťWebÔÇŁ esaslar─▒n─▒ kullanarak belirli ilkelere dayanan mimari bir stildir. REST hizmetleri olu┼čturmak i├žin kullan─▒lan 5 temel web temel vard─▒r.

  • ─░lke 1: Her ┼čey Bir Kaynakt─▒r REST mimari tarz─▒nda, veri ve i┼člevsellik kaynaklar olarak kabul edilir ve genellikle Web ├╝zerindeki ba─člant─▒lar olan Tekd├╝zen Kaynak Tan─▒mlay─▒c─▒lar─▒ (URI'ler) kullan─▒larak eri┼čilir.
  • ─░lke 2: Her Kaynak Benzersiz Bir Tan─▒mlay─▒c─▒ (URI) ile Tan─▒mlan─▒yor
  • ─░lke 3: Basit ve D├╝zg├╝n Aray├╝zler Kullan─▒n
  • ─░lke 4: ─░leti┼čim, Temsil ─░le Ger├žekle┼čtirildi
  • ─░lke 5: Vatans─▒z Olmak

38







"/ User / 123" kayna─č─▒na kullan─▒c─▒ 123 ile ilgili her ┼čeyi koyman─▒n RESTful oldu─čunu s├Âyleyen bir├žok yan─▒t g├Âr├╝yorum.

Bu terimi olu┼čturan Roy Fielding, REST API'lerinin k├Âpr├╝ metni odakl─▒ olmas─▒ gerekti─čini s├Âyledi . ├ľzellikle, "Bir REST API'si sabit kaynak adlar─▒n─▒ veya hiyerar┼čilerini tan─▒mlamamal─▒d─▒r".

Bu nedenle, "/ user / 123" yolunuz istemcide kodlanm─▒┼čsa, bu ger├žekten RESTful de─čildir. HTTP'nin iyi bir kullan─▒m─▒, belki, belki de de─čil. Ama RESTful de─čil. K├Âpr├╝ metninden gelmek zorunda.


33


2009-03-22





Cevap ├žok basit, Roy Fielding taraf─▒ndan yaz─▒lm─▒┼č bir tez var .] 1 Bu tezde REST ilkelerini tan─▒mlar. Bir uygulama bu ilkeleri yerine getirirse, bu bir REST uygulamas─▒d─▒r.

RESTful terimi, ppl, REST olmayan uygulamalar─▒n─▒ REST olarak ├ža─č─▒rarak REST s├Âzc├╝─č├╝n├╝ t├╝ketti─či i├žin yarat─▒ld─▒. Bundan sonra RESTful terimi de t├╝kendi. Bug├╝nlerde Web API'leri ve Hypermedia API'leri hakk─▒nda konu┼čuyoruz , ├ž├╝nk├╝ REST uygulamalar─▒n─▒n ├žo─ču tek tip arabirim k─▒s─▒tlamas─▒n─▒n HATEOAS b├Âl├╝m├╝n├╝ yerine getirmedi.

REST k─▒s─▒tlamalar─▒ a┼ča─č─▒daki gibidir:

  1. istemci-sunucu mimarisi

    Bu y├╝zden ├Ârne─čin PUB / SUB soketleri ile ├žal─▒┼čmaz, REQ / REP'ye dayan─▒r.

  2. vatans─▒z ileti┼čim

    B├Âylece sunucu istemcilerin durumlar─▒n─▒ korumaz. Bu, sunucuyu bir yan oturum depolamas─▒ kullanamayaca─č─▒n─▒z ve her iste─či do─črulaman─▒z gerekti─či anlam─▒na gelir. M├╝┼čterileriniz muhtemelen temel auth ba┼čl─▒klar─▒n─▒ ┼čifreli bir ba─člant─▒ yoluyla g├Ânderir. (B├╝y├╝k uygulamalarla bir├žok oturumu s├╝rd├╝rmek zordur.)

  3. e─čer ├Ânbellek kullan─▒m─▒

    B├Âylece ayn─▒ talepleri tekrar tekrar yerine getirmeniz gerekmez.

  4. istemci ve sunucu aras─▒nda ortak s├Âzle┼čme olarak tek tip aray├╝z

    ─░stemci ile sunucu aras─▒ndaki s├Âzle┼čme sunucu taraf─▒ndan yap─▒lmaz. Ba┼čka bir deyi┼čle, m├╝┼čteri hizmetin uygulanmas─▒ndan ayr─▒lmal─▒d─▒r. Bu duruma, kaynaklar─▒ tan─▒mlamak i├žin IRI (URI) standard─▒, mesaj al─▒┼čveri┼či i├žin HTTP standard─▒, v├╝cut serile┼čtirme format─▒n─▒ tan─▒mlamak i├žin standart MIME t├╝rleri, meta verileri (muhtemelen RDF s├Âzc├╝kleri, mikro bi├žimler vb.) Kullanarak standart ├ž├Âz├╝mleri kullanarak ula┼čabilirsiniz. Mesaj g├Âvdesinin farkl─▒ b├Âl├╝mlerinin anlamlar─▒n─▒ a├ž─▒klar. IRI yap─▒s─▒n─▒ istemciden ay─▒rmak i├žin, istemcilere (HTML, JSON-LD, HAL vb.) Hiper medya bi├žimlerinde k├Âpr├╝ler g├Ândermeniz gerekir. B├Âylece bir m├╝┼čteri mevcut hedefine ula┼čmak i├žin uygulaman─▒n durum makinesinde uygun durum ge├ži┼čleri aras─▒nda gezinmek i├žin k├Âpr├╝lere atanan meta verileri (muhtemelen ba─člant─▒ ili┼čkileri, RDF s├Âzc├╝kleri) kullanabilir.

    ├ľrne─čin, bir m├╝┼čteri bir web ma─čazas─▒na sipari┼č g├Ândermek istedi─činde, web ma─čazas─▒n─▒n g├Ânderdi─či yan─▒tlardaki k├Âpr├╝leri kontrol etmek zorundad─▒r. Ba─člant─▒lar─▒ kontrol ederek, http://schema.org/OrderAction ile a├ž─▒klanan bir ba─člant─▒ buldu . M├╝┼čteri schema.org s├Âzl├╝─č├╝n├╝ bilir, bu y├╝zden bu k├Âpr├╝y├╝ aktif hale getirerek sipari┼či g├Ânderece─čini anlar. B├Âylece k├Âpr├╝y├╝ etkinle┼čtirir ve POST https://example.com/api/v1/order uygun g├Âvdeyle bir mesaj g├Ânderir . Bundan sonra, servis mesaj─▒ i┼čler ve ├Ârne─čin 201 - created , ba┼čar─▒ ile , uygun HTTP durum ba┼čl─▒─č─▒na sahip olan sonu├žla yan─▒t verir . Bir RDF format─▒, ├Ârne─čin bir REST kelimesi ile JSON-LD , ├Ârne─čin, Schema.org gibi Hydra ve etki alan─▒na ├Âzg├╝ kelimeler veya ba┼čka bir ba─člant─▒l─▒ veri kelimesi ve belki de ├Âzel bir uygulamaya ├Âzg├╝ kelime bilgisi gibi standart veri i├žeren mesajlara not eklemek gerekli. ┼×imdi bu kolay de─čil, ppl'nin ├žo─čunun HAL ve di─čer basit formatlar─▒ kullanmas─▒, genellikle yaln─▒zca REST kelime haznesi veriyor, ancak ba─člant─▒l─▒ veri deste─či yok.http://schema.org/http://lov.okfn.org/dataset/lov/

  5. ├Âl├žeklenebilirli─či art─▒rmak i├žin katmanl─▒ bir sistem kurmak

    REST sistemi hiyerar┼čik katmanlardan olu┼čur. Her katman, bir sonraki katmandaki bile┼čenlerin hizmetlerini kullanan bile┼čenler i├žerir. B├Âylece zahmetsizce yeni katmanlar ve bile┼čenler ekleyebilirsiniz.

    ├ľrne─čin, istemcileri i├žeren bir istemci katman─▒ vard─▒r ve bunun alt─▒nda tek bir servis i├žeren bir servis katman─▒ vard─▒r. ┼×imdi aralar─▒na bir istemci taraf─▒ ├Ânbellek ekleyebilirsiniz. Bundan sonra ba┼čka bir servis ├Ârne─či ve bir y├╝k dengeleyici vb. Ekleyebilirsiniz. ─░stemci kodu ve servis kodu de─či┼čmez.

  6. ─░stemci i┼člevselli─čini geni┼čletmek i├žin talep ├╝zerine kod

    Bu k─▒s─▒tlama iste─če ba─čl─▒d─▒r. ├ľrne─čin, istemciye belirli bir medya t├╝r├╝ i├žin bir ayr─▒┼čt─▒r─▒c─▒ g├Ânderebilirsiniz, vb. ... Bunu yapmak i├žin istemcide standart bir eklenti y├╝kleyici sisteme ihtiyac─▒n─▒z olabilir veya istemciniz eklenti y├╝kleyici ├ž├Âz├╝m├╝ne ba─član─▒r .

REST k─▒s─▒tlamalar─▒, istemcilerin hizmetlerin uygulamalar─▒ndan ayr─▒ld─▒─č─▒ y├╝ksek ├Âl├žeklenebilir bir sisteme neden olur. B├Âylece istemciler, t─▒pk─▒ web'deki taray─▒c─▒lar gibi, genel olarak yeniden kullan─▒labilir. M├╝┼čteriler ve hizmetler ayn─▒ standartlar─▒ ve s├Âzc├╝kleri payla┼č─▒r, b├Âylece m├╝┼čterinin hizmetin uygulama ayr─▒nt─▒lar─▒n─▒ bilmemesine ra─čmen birbirlerini anlayabilirler. Bu, hedeflerine ula┼čmak i├žin REST servislerini bulabilen ve kullanan otomatik m├╝┼čteriler yaratmay─▒ m├╝mk├╝n k─▒lar. Uzun vadede bu m├╝┼čteriler birbirleriyle ileti┼čim kurabilir ve t─▒pk─▒ insanlar─▒n yapt─▒─č─▒ gibi g├Ârevlerle birbirlerine g├╝venebilirler. Bu t├╝r istemcilere ├Â─črenme kal─▒plar─▒ eklersek, sonu├ž tek bir sunucu park─▒ yerine makinelerin a─č─▒n─▒ kullanan bir veya daha fazla AI olacakt─▒r. Sonunda Berners Lee'nin r├╝yas─▒: anlamsal a─č ve yapay zeka ger├žek olacak. B├Âylece 2030 y─▒l─▒nda Skynet taraf─▒ndan sonland─▒r─▒ld─▒k. O zamana kadar ... ;-)


26







RESTful (Temsili durum aktar─▒m─▒) API programlama, 5 temel yaz─▒l─▒m mimari tarz─▒ ilkesini izleyerek, herhangi bir programlama dilinde web uygulamalar─▒ yaz─▒yor :

  1. Kaynak (veri, bilgi).
  2. E┼čsiz genel tan─▒mlay─▒c─▒ (t├╝m kaynaklar URI taraf─▒ndan tan─▒mlanm─▒┼čt─▒r ).
  3. D├╝zg├╝n arabirim - basit ve standart arabirim (HTTP) kullan─▒n.
  4. Temsil - t├╝m ileti┼čim temsil ile yap─▒l─▒r (├Ârne─čin, XML / JSON ).
  5. Vatans─▒zl─▒k (her istek eksiksiz bir izolasyonda ger├žekle┼čir, ├Ânbelleklenmesi ve y├╝k dengesi daha kolayd─▒r),

Ba┼čka bir deyi┼čle, her bir "kayna─č─▒n" ortaya koydu─ču aray├╝z├╝n standartla┼čt─▒r─▒lmas─▒n─▒ ├Âneren RESTful mimarisini uygulayarak GET, POST, PUT veya DELETE gibi fiiller kullanan HTTP ├╝zerinden basit noktadan noktaya a─č uygulamalar─▒ yaz─▒yorsunuz. Web'in ┼ču anki ├Âzelliklerini basit ve etkili bir ┼čekilde (├žok ba┼čar─▒l─▒, kan─▒tlanm─▒┼č ve da─č─▒t─▒lm─▒┼č mimari) kullanmaktan ba┼čka bir ┼čey de─čildir. SOAP , CORBA ve RPC gibi daha karma┼č─▒k mekanizmalara bir alternatiftir .

RESTful programlama, Web mimarisi tasar─▒m─▒na uygundur ve uygun ┼čekilde uygulan─▒rsa, ├Âl├žeklenebilir Web altyap─▒s─▒ndan tam olarak yararlanman─▒za olanak tan─▒r.


21







REST konusundaki orijinal tez ├žal─▒┼čmas─▒n─▒ sadece 3 k─▒sa c├╝mleye d├╝┼č├╝rmek zorunda olsayd─▒m, a┼ča─č─▒dakilerin ├Âz├╝n├╝ yakalad─▒─č─▒n─▒ d├╝┼č├╝n├╝yorum:

  1. Kaynaklar URL'ler arac─▒l─▒─č─▒yla talep edilir.
  2. Protokoller, URLÔÇÖleri kullanarak ileti┼čim kurabileceklerinizle s─▒n─▒rl─▒d─▒r.
  3. Meta veriler, ad-de─čer ├žiftleri olarak ge├žirilir (veri sonras─▒ ve sorgu dizesi parametreleri).

Bundan sonra, uyarlamalar, kodlama kurallar─▒ ve en iyi uygulamalar hakk─▒nda tart─▒┼čmalara d├╝┼čmek kolayd─▒r.

─░lgin├ž bir ┼čekilde, tez ├žal─▒┼čmas─▒nda HTTP POST, GET, DELETE veya PUT i┼člemlerinden s├Âz edilmez. Bu, birisinin daha sonra "homojen bir aray├╝z" i├žin "en iyi uygulama" n─▒n yorumlanmas─▒ olmal─▒d─▒r.

Web hizmetleri s├Âz konusu oldu─čunda, WSDL ve SOAP tabanl─▒ mimarileri farkl─▒ k─▒lmak i├žin bir aray├╝ze ihtiyac─▒m─▒z var gibi g├Âr├╝n├╝yor. Ayr─▒ca, uygulanmas─▒ i├žin ek ├žer├ževeler ve geli┼čtirici ara├žlar─▒ da gerektirir. REST'in sa─čduyulu arabirimler ile WSDL ve SOAP gibi a┼č─▒r─▒ yap─▒land─▒r─▒lm─▒┼č arabirimler aras─▒nda ayr─▒m yapmak i├žin en iyi terim olup olmad─▒─č─▒ndan emin de─čilim. Ama bir ┼čeye ihtiyac─▒m─▒z var.


17







REST, mimari bir desen ve da─č─▒t─▒k uygulama yazma tarz─▒d─▒r. Dar anlamda bir programlama tarz─▒ de─čil.

REST tarz─▒n─▒ kulland─▒─č─▒n─▒z─▒ s├Âylemek, belirli bir tarzda bir ev in┼ča etti─činize benzer: Mesela Tudor veya Victoria. Hem bir yaz─▒l─▒m stili olarak REST hem de bir ev stili olarak Tudor veya Victoria, bunlar─▒ olu┼čturan nitelikler ve k─▒s─▒tlamalar ile tan─▒mlanabilir. ├ľrne─čin, REST, mesajlar─▒n kendini tan─▒mlad─▒─č─▒ M├╝┼čteri Sunucusu ayr─▒m─▒na sahip olmal─▒d─▒r. Tudor tarz─▒ evlerde ├╝st ├╝ste binen ─▒zgaralar ve ├Ân tarafa bakacak ┼čekilde dik duran perdeli ├žat─▒lar var. Roy'un tezini, REST'i olu┼čturan k─▒s─▒tlamalar ve nitelikler hakk─▒nda daha fazla bilgi edinmek i├žin okuyabilirsiniz.

Ev stillerinden farkl─▒ olarak REST, tutarl─▒ ve pratik bir ┼čekilde uygulanmakta zorland─▒. Bu kas─▒tl─▒ olabilir. Ger├žek uygulamas─▒n─▒ tasar─▒mc─▒ya b─▒rakarak. Bu nedenle, tezde belirtilen k─▒s─▒tlamalara uydu─čunuz s├╝rece REST Sistemlerini yaratt─▒─č─▒n─▒z s├╝rece istedi─činizi yapmakta ├Âzg├╝rs├╝n├╝z.

Bonus:

T├╝m web REST'e dayan─▒r (veya REST web'e dayand─▒r─▒lm─▒┼čt─▒r). Bu nedenle, bir web geli┼čtiricisi olarak iyi web uygulamalar─▒ yazmak gerekmese de bunun fark─▒nda olmak isteyebilirsiniz.


17







─░┼čte benim REST'in temel tasla─č─▒. Her bir bile┼čenin arkas─▒ndaki d├╝┼č├╝nceyi RESTful bir mimaride g├Âstermeye ├žal─▒┼čt─▒m, b├Âylece kavram─▒ anlamak daha sezgiseldi. Umar─▒m bu, baz─▒ insanlar i├žin REST'in gizemini kald─▒rmas─▒na yard─▒mc─▒ olur!

REST (Temsili Durum Aktar─▒m─▒) a─č ba─člant─▒l─▒ kaynaklar─▒n (yani bilgi payla┼čan d├╝─č├╝mlerin) nas─▒l tasarland─▒─č─▒n─▒ ve ele al─▒nd─▒─č─▒n─▒ belirleyen bir tasar─▒m mimarisidir. Genel olarak, bir RESTful mimarisi, istemcinin (istekte bulunan makine) ve sunucunun (yan─▒t veren makine), sunucunun nas─▒l ├žal─▒┼čt─▒─č─▒n─▒ ve sunucunun nas─▒l ge├žebilece─čini bilmesine gerek kalmadan verileri okuma, yazma ve g├╝ncelleme talebinde bulunmas─▒n─▒ sa─člar. m├╝┼čteri hakk─▒nda hi├žbir ┼čey bilmeden geri d├Ând├╝. Tamam, harika ... ama bunu pratikte nas─▒l yapar─▒z?

  • En belirgin gereksinim, sunucunun m├╝┼čteriye istekle ve sunucunun yan─▒t vermesi i├žin ne yapmaya ├žal─▒┼čt─▒─č─▒n─▒ anlayabilmesi i├žin bir t├╝r evrensel dil olmas─▒ gerekti─čidir.

  • Ancak, herhangi bir kayna─č─▒ bulmak ve ard─▒ndan m├╝┼čteriye bu kayna─č─▒n nerede ya┼čad─▒─č─▒n─▒ s├Âylemek i├žin, kaynaklara i┼čaret etmenin evrensel bir yolunun olmas─▒ gerekir. Buras─▒ Evrensel Kaynak Tan─▒mlay─▒c─▒lar─▒n─▒n (URI'ler) geldi─či yerdir; kaynaklar─▒ bulmak i├žin temelde benzersiz adreslerdir.

Ancak REST mimarisi burada bitmiyor! Yukar─▒dakiler, istediklerimizin temel ihtiya├žlar─▒n─▒ kar┼č─▒larken, ayn─▒ zamanda herhangi bir sunucu genellikle ├žok say─▒da m├╝┼čteriden gelen yan─▒tlar─▒ ele ald─▒─č─▒ndan y├╝ksek hacimli trafi─či destekleyen bir mimariye sahip olmak istiyoruz. Bu nedenle, ├Ânceki istekler hakk─▒ndaki bilgileri hat─▒rlatarak sunucuyu bo─čmak istemeyiz.

  • Bu nedenle, istemci ile sunucu aras─▒ndaki her istek-yan─▒t ├žiftinin ba─č─▒ms─▒z oldu─ču k─▒s─▒tlamas─▒n─▒ uygular─▒z, yani sunucunun yeni bir yan─▒t vermek i├žin ├Ânceki isteklerle (istemci-sunucu etkile┼čiminin ├Ânceki durumlar─▒) hi├žbir ┼čey hat─▒rlamas─▒ gerekmez. istek. Bu, etkile┼čimlerimizin vatans─▒z olmas─▒n─▒ istedi─čimiz anlam─▒na geliyor.

  • Sunucumuzdaki zorlamay─▒, belirli bir m├╝┼čteri i├žin yak─▒n zamanda yap─▒lm─▒┼č olan hesaplamalar─▒ yeniden yapmaktan daha da kolayla┼čt─▒rmak i├žin REST ayr─▒ca ├Ânbelleklemeye de izin verir. Temel olarak, ├Ânbellekleme, m├╝┼čteriye verilen ilk yan─▒t─▒n anl─▒k g├Âr├╝nt├╝s├╝n├╝ almak anlam─▒na gelir. ─░stemci ayn─▒ iste─či tekrar yaparsa, sunucu m├╝┼čteriye ilk yan─▒t─▒ olu┼čturmak i├žin gerekli t├╝m hesaplamalar─▒ yinelemek yerine anl─▒k g├Âr├╝nt├╝ sa─člayabilir. Ancak, anl─▒k g├Âr├╝nt├╝ oldu─čundan, anl─▒k g├Âr├╝nt├╝ s├╝resinin sona ermemesi durumunda - sunucu ├Ânceden bir son kullanma s├╝resi belirler - ve ilk ├Ânbellekten bu yana yan─▒t g├╝ncellendi (yani istek ├Ânbelle─če al─▒nan yan─▒ttan farkl─▒ bir cevap verir) ─░stemci, ├Ânbellek sona erinceye (ya da ├Ânbellek silinene kadar) ve yan─▒t yeniden s─▒f─▒rdan al─▒nana kadar g├╝ncellemeleri g├Ârmez.

  • RESTful mimarileri hakk─▒nda s─▒k s─▒k burada kalaca─č─▒n─▒z son ┼čey, katmanl─▒ olmalar─▒d─▒r. Asl─▒nda bu gereksinimi, istemci ile sunucu aras─▒ndaki etkile┼čimi tart─▒┼čmam─▒zda zaten dolayl─▒ olarak tart─▒┼č─▒yorduk. Temel olarak, bu, sistemimizdeki her katman─▒n yaln─▒zca biti┼čik katmanlarla etkile┼čime girdi─či anlam─▒na gelir. Dolay─▒s─▒yla, tart─▒┼čmam─▒zda, istemci katman─▒ sunucu katman─▒m─▒zla etkile┼čime girer (ve tam tersi), ancak birincil sunucunun, istemcinin do─črudan ileti┼čim kurmad─▒─č─▒ bir iste─či i┼člemesine yard─▒mc─▒ olan ba┼čka sunucu katmanlar─▒ olabilir. Aksine, sunucu iste─či ├╝zerine gerekti─či gibi iletir.

┼×imdi, bunlar─▒n hepsi tan─▒d─▒k geliyorsa, o zaman harika. World Wide Web ├╝zerinden ileti┼čim protokol├╝n├╝ tan─▒mlayan K├Âpr├╝ Metni Aktar─▒m Protokol├╝ (HTTP), RESTful mimarisinin (ya da benim gibi bir OOP fanati─či iseniz REST s─▒n─▒f─▒n─▒n bir ├Ârne─či) soyut kavram─▒n─▒n bir uygulamas─▒d─▒r. REST'in bu uygulamas─▒nda, istemci ve sunucu, evrensel dilin bir par├žas─▒ olan GET, POST, PUT, DELETE vb. ─░le etkile┼čime girer ve kaynaklar URL'lerin kullan─▒lmas─▒na i┼čaret edilebilir.


17


2017-03-31





─░nternetten (protokol) vatans─▒z bir ta┼č─▒ma katman─▒ olarak yararlan─▒rken dinlenmenin as─▒l durumun daha y├╝ksek bir katmana ayr─▒lmas─▒ oldu─čunu d├╝┼č├╝n├╝yorum . Di─čer bir├žok yakla┼č─▒m i┼čleri kar─▒┼čt─▒r─▒r.

─░nternet ├ža─č─▒nda programlaman─▒n temel de─či┼čikliklerini ele almak i├žin en iyi pratik yakla┼č─▒m olmu┼čtur. Temel de─či┼čikliklerle ilgili olarak, Erik Meijer'in burada g├Âsterdi─či bir tart─▒┼čma var: http://www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity#view_93197 . Be┼č etki olarak ├Âzetler ve ├ž├Âz├╝m├╝ bir programlama dilinde tasarlayarak bir ├ž├Âz├╝m sunar. ├ç├Âz├╝m, dilden ba─č─▒ms─▒z olarak platformda veya sistem d├╝zeyinde de sa─članabilir. Dinlendirici, mevcut uygulamada ├žok ba┼čar─▒l─▒ olan ├ž├Âz├╝mlerden biri olarak g├Âr├╝lebilir.

Huzurlu bir stille, g├╝venilir bir internet ├╝zerinden uygulaman─▒n durumunu al─▒p de─či┼čtirirsiniz. Ge├žerli i┼člemi do─čru ve g├╝ncel duruma getiremezse, uygulaman─▒n devam etmesine yard─▒mc─▒ olmak i├žin s─▒f─▒r do─črulama ilkesine ihtiya├ž duyar. Durumu de─či┼čtiremezse, i┼čleri do─čru tutmak i├žin genellikle birden fazla onay a┼čamas─▒ kullan─▒r. Bu anlamda dinlenme tamamen bir ├ž├Âz├╝m de─čildir, ├žal─▒┼čmas─▒n─▒ desteklemek i├žin web uygulamas─▒ y─▒─č─▒n─▒n─▒n di─čer b├Âl├╝m├╝ndeki i┼člevlere ihtiya├ž duyar.

Bu bak─▒┼č a├ž─▒s─▒ g├Âz ├Ân├╝ne al─▒nd─▒─č─▒nda, dinlenme tarz─▒ ger├žekten internet veya web uygulamas─▒na ba─čl─▒ de─čildir. Programlama durumlar─▒n─▒n ├žo─ču i├žin temel bir ├ž├Âz├╝md├╝r. Her ikisi de basit de─čil, sadece aray├╝z├╝ ger├žekten basit hale getiriyor ve di─čer teknolojilerle inan─▒lmaz derecede iyi ba┼ča ├ž─▒k─▒yor.

Sadece benim 2c.

D├╝zenleme: ─░ki daha ├Ânemli ├Âzellik:


15







Bu ┼ča┼č─▒rt─▒c─▒ derecede uzun bir "tart─▒┼čma" ve en az─▒n─▒ s├Âylemek olduk├ža kafa kar─▒┼čt─▒r─▒c─▒.

IMO:

1) B├╝y├╝k bir ortak ve ├žok fazla bira olmadan dinlendirici programlama gibi bir ┼čey yoktur :)

2) Temsili Devlet Transferi (REST), Roy Fielding'in tezinde belirtilen mimari bir stildir . Bir tak─▒m k─▒s─▒tlamalar─▒ var. Hizmetiniz / M├╝┼čteriniz bunlara sayg─▒ duyuyorsa, RESTful'd─▒r. Budur.

K─▒s─▒tlamalar─▒ (├Ânemli ├Âl├ž├╝de) ┼ču ┼čekilde ├Âzetleyebilirsiniz:

  • vatans─▒z ileti┼čim
  • HTTP ├Âzelliklerine uyun (e─čer HTTP kullan─▒l─▒yorsa)
  • iletilen i├žerik bi├žimlerini a├ž─▒k├ža iletir
  • Hypermedia'y─▒ uygulama durumunun motoru olarak kullanabilir

G├╝zel ┼čeyler anlatan ba┼čka ├žok iyi bir yaz─▒ var.

Bir├žok cevap, bilgiyi kar─▒┼čt─▒rarak ve biraz kar─▒┼č─▒kl─▒k katan ge├žerli bilgiyi kopyalar / yap─▒┼čt─▒r─▒r. ─░nsanlar burada seviyelerden, RESTFul URI'lerden (b├Âyle bir ┼čey yoktur!) Bahsediyorlar, HTTP y├Ântemlerini uygularlar GET, POST, PUT ... REST bununla ilgili de─čil ya da bununla ilgili de─čil.

├ľrne─čin, ba─člant─▒lar - g├╝zel g├Âr├╝n├╝ml├╝ bir APIÔÇÖye sahip olmak g├╝zeldir, ancak sonunda m├╝┼čteri / sunucu sizin ald─▒─č─▒n─▒z / g├Ânderdi─činiz ba─člant─▒lar─▒ ├Ânemsemez.

Sonunda, herhangi bir RESTful istemcisi, i├žerik format─▒ bilindi─či s├╝rece herhangi bir RESTful hizmetini kullanabilmelidir.


14







Eski soru, cevaplaman─▒n newish yolu. D─▒┼čar─▒da bu kavram hakk─▒nda bir ├žok yanl─▒┼č anla┼č─▒lma var. Her zaman hat─▒rlamaya ├žal─▒┼č─▒r─▒m:

  1. Yap─▒land─▒r─▒lm─▒┼č URL'ler ve Http Y├Ântemleri / Fiiller dinlendirici programlaman─▒n tan─▒m─▒ de─čildir.
  2. JSON dinlendirici programlama de─čil
  3. RESTful programlama, API'ler i├žin de─čildir

Dinlendirici programlamay─▒ ┼ču ┼čekilde tan─▒mlar─▒m:

Bir m├╝┼čteri, m├╝┼čterinin anlad─▒─č─▒ bir medya t├╝r├╝nde kaynaklar (veri / durum ge├ži┼čleri kontrollerinin birle┼čimidir) sa─čl─▒yorsa huzurludur

Dinlendirici bir programc─▒ olmak i├žin, oyuncular─▒n bir ┼čeyler yapmas─▒na izin veren uygulamalar olu┼čturmaya ├žal─▒┼č─▒yor olmal─▒s─▒n─▒z. Sadece veritaban─▒n─▒ g├Âstermek de─čil.

Durum ge├ži┼č denetimleri, yaln─▒zca m├╝┼čteri ve sunucu kayna─č─▒n ortam t├╝r├╝n├╝ temsil etmesi konusunda hemfikir oldu─čunda anlaml─▒d─▒r. Aksi halde, neyin kontrol oldu─čunu ve neyin olmad─▒─č─▒n─▒ ve kontrol├╝n nas─▒l uygulanaca─č─▒n─▒ bilmenin bir yolu yoktur. IE, e─čer taray─▒c─▒lar html'de <form> etiketleri bilmiyorlarsa , taray─▒c─▒n─▒zdaki ge├ži┼č durumuna g├Ândermeniz i├žin hi├žbir ┼čey olmazd─▒ .

Kendimi tan─▒tmak istemiyorum ama bu fikirleri konu┼čmamda derinlemesine geni┼čletiyorum http://techblog.bodybuilding.com/2016/01/video-what-is-restful-200.html .

Konu┼čmamdan bir al─▒nt─▒, genellikle richardson vade modeline at─▒fta bulunulmas─▒yla ilgilidir, seviyelere inanm─▒yorum, ya RESTful (seviye 3) ya da de─čilsin, ama bununla ilgili olarak s├Âylemek istedi─čim, her seviyenin ne oldu─ču RESTful yolunda senin i├žin yapar


a├ž─▒klamal─▒ richardson vade modeli


14







REST, herhangi bir web servisini yapan 6 mimari k─▒s─▒tlama tan─▒mlamaktad─▒r - ger├žek bir RESTful API .

  1. Tek tip aray├╝z├╝
  2. M├╝┼čteri sunucusu
  3. vatans─▒z
  4. cacheable
  5. Katmanl─▒ sistem
  6. Talep ├╝zerine kod (iste─če ba─čl─▒)

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


12







REST === HATEOAS taraf─▒ndan y├Ânlendirilmesi gerekti─čini " GER├çEK " durumuna vurgu yapana kadar HTTP analojisi do─čru de─čil .

Roy kendisi burada temizledi .

Bir REST API, ilk URI (yer imi) d─▒┼č─▒nda ve ├Ânceden belirlenmi┼č bir hedef kitleye uygun (yani, API'yi kullanacak herhangi bir m├╝┼čteri taraf─▒ndan anla┼č─▒lmas─▒ beklendi─či gibi) standartla┼čt─▒r─▒lm─▒┼č medya t├╝rlerinin ├Âtesinde hi├žbir bilgi olmadan girilmelidir. Bu noktadan itibaren, t├╝m uygulama durumu ge├ži┼čleri, al─▒nan temsillerde bulunan veya kullan─▒c─▒n─▒n bu sunumlar─▒ manip├╝le etmesiyle ima edilen sunucu taraf─▒ndan sa─članan se├ženeklerin m├╝┼čteri se├žimi taraf─▒ndan y├Ânlendirilmelidir. Ge├ži┼čler, m├╝┼čterinin her ikisi de an─▒nda geli┼čtirilebilecek medya t├╝rleri ve kaynak ileti┼čim mekanizmalar─▒ hakk─▒ndaki bilgileri belirleyebilir (veya bunlarla s─▒n─▒rl─▒ olabilir) (├Ârne─čin, talep ├╝zerine kod).

[Buradaki ba┼čar─▒s─▒zl─▒k, bant d─▒┼č─▒ bilgilerin k├Âpr├╝ metni yerine etkile┼čimi sa─člad─▒─č─▒n─▒ g├Âsteriyor.]


11







REST , web standartlar─▒na ve HTTP protokol├╝ne dayal─▒ (2000'de tan─▒t─▒lan) bir mimari tarzd─▒r.

REST tabanl─▒ bir mimaride her ┼čey bir kaynakt─▒r (Kullan─▒c─▒lar, Sipari┼čler, Yorumlar). Bir kayna─ča, HTTP standart y├Ântemlerine (GET, PUT, PATCH, DELETE vb.) Dayanan ortak bir aray├╝z arac─▒l─▒─č─▒yla eri┼čilir.

REST tabanl─▒ bir mimaride, kaynaklara eri┼čim sa─člayan bir REST sunucunuz var. Bir REST istemcisi REST kaynaklar─▒na eri┼čebilir ve bunlar─▒ de─či┼čtirebilir.

Her kaynak HTTP ortak i┼člemlerini desteklemelidir. Kaynaklar global ID'ler (tipik olarak URI'lar) ile tan─▒mlan─▒r.

REST, kaynaklar─▒n, ├Ârne─čin metin, XML, JSON, vb. Gibi farkl─▒ temsillere sahip olmas─▒n─▒ sa─člar. REST istemcisi, HTTP protokol├╝ (i├žerik g├Âr├╝┼čmesi) arac─▒l─▒─č─▒yla belirli bir g├Âsterim isteyebilir.

HTTP y├Ântemleri:

PUT, GET, POST ve DELETE y├Ântemleri REST tabanl─▒ mimarilerde tipik olarak kullan─▒l─▒r. A┼ča─č─▒daki tablo bu i┼člemlerin bir a├ž─▒klamas─▒n─▒ vermektedir.

  • GET, yan etki olmadan kayna─č─▒n okuma eri┼čimini tan─▒mlar. Kaynak bir GET iste─či ile asla de─či┼čtirilmez, ├Ârne─čin, iste─čin hi├žbir yan etkisi yoktur (ba─č─▒ms─▒z).
  • PUT yeni bir kaynak yarat─▒r. Ayn─▒ zamanda ├Ânemsiz olmal─▒.
  • S─░L, kaynaklar─▒ kald─▒r─▒r. ─░┼člemler ├Ânemsizdir. Farkl─▒ sonu├žlara yol a├žmadan tekrarlanabilirler.
  • POST, mevcut bir kayna─č─▒ g├╝nceller veya yeni bir kaynak olu┼čturur.

11







REST , Temsil halindeki devir anlam─▒na gelir .

Vatans─▒z, m├╝┼čteri-sunucu, ├Ânbelleklenebilir ileti┼čim protokol├╝ne dayan─▒r - ve hemen hemen her durumda, HTTP protokol├╝ kullan─▒l─▒r.

REST genellikle mobil uygulamalarda, sosyal a─č sitelerinde, mashup ara├žlar─▒nda ve otomatik i┼č s├╝re├žlerinde kullan─▒l─▒r. REST tarz─▒, m├╝┼čteriler ve hizmetler aras─▒ndaki etkile┼čimin, s─▒n─▒rl─▒ say─▒da i┼člem yap─▒larak (fiiller) geli┼čtirildi─čini vurgulamaktad─▒r. Kaynaklara (isimlere) kendi benzersiz evrensel kaynak g├Âstergelerini (URI'leri) atayarak esneklik sa─član─▒r.

Dinlenme hakk─▒nda giri┼č


10







Konu┼čma basit├že bilgi al─▒┼čveri┼činden daha fazlas─▒d─▒r . Bir Protokol asl─▒nda hi├žbir konu┼čman─▒n ger├žekle┼čmeyece─či ┼čekilde tasarlanm─▒┼čt─▒r. Her parti kendi i┼činin ne oldu─čunu bilir ├ž├╝nk├╝ protokolde belirtilmi┼čtir. Protokoller, olas─▒ eylemlerde herhangi bir de─či┼čiklik yapmak pahas─▒na, saf bilgi al─▒┼čveri┼čine izin verir. Konu┼čmak, di─čer taraftan, bir taraf─▒n di─čer taraftan ne gibi ├Ânlemler al─▒nabilece─čini sormas─▒n─▒ sa─člar. Ayn─▒ soruyu iki kez bile sorabilir ve iki taraf─▒n cevab─▒n─▒ alabilir, ├ž├╝nk├╝ di─čer taraf─▒n Devleti bu arada de─či┼čmi┼č olabilir. Konu┼čmak RESTful mimarisidir . Fielding'in tezi, makinelerin basit├že ileti┼čim kurmak yerine birbirleriyle konu┼čmas─▒na izin vermek isterse izlenmesi gereken mimariyi belirler .


10







Kendi ba┼č─▒na "RESTful programlama" diye bir kavram yoktur. Daha iyi RESTful paradigmas─▒ veya daha iyi RESTful mimarisi olarak adland─▒r─▒labilir. Bu bir programlama dili de─čil. Bu bir paradigmad─▒r.

Wikipedia'dan :

Bilgi i┼člemde, temsili durum aktar─▒m─▒ (REST), web geli┼čtirme i├žin kullan─▒lan mimari bir stildir.


10


2016-08-24





Dinlenmenin amac─▒, temel i┼člemler (http fiilleri) i├žin ortak bir dil kullanmay─▒ kabul edersek, altyap─▒n─▒n, onlar─▒ ├Ânbelle─če almak i├žin ├Ânbellekleme uygulamalar─▒ndan yararlanarak, onlar─▒ anlamak ve d├╝zg├╝n bir ┼čekilde optimize etmek i├žin yap─▒land─▒r─▒labilece─čidir. seviyeleri.

D├╝zg├╝n bir ┼čekilde uygulanan dinlendirici GET i┼člemi ile, bilgilerin sunucunuzun DB'sinden, sunucunuzun memcache'sinden, CDN'sinden, proxy ├Ânbelle─činden, taray─▒c─▒n─▒z─▒n ├Ânbelle─činden veya taray─▒c─▒n─▒z─▒n yerel deposundan gelip gelmemesi ├Ânemli de─čildir. Oru├ž, en g├╝ncel kaynaklara en kolay ┼čekilde kullan─▒labilir.

Rest'in, GET isteklerini bir eylem parametresiyle kullanmaktan, mevcut http fiillerini kullanmaktan s├Âzdizimsel bir de─či┼čiklik oldu─čunu s├Âylemek, faydas─▒ yokmu┼č gibi g├Âr├╝nmesini sa─člar ve tamamen kozmetiktir. Mesele, zincirin her par├žas─▒ taraf─▒ndan anla┼č─▒labilecek ve optimize edilebilecek bir dil kullanmakt─▒r. GET i┼čleminizde yan etkiler olan bir eylem varsa, t├╝m HTTP ├Ânbelle─če almay─▒ atlaman─▒z gerekir, aksi takdirde tutars─▒z sonu├žlarla sonu├žlan─▒rs─▒n─▒z.


9







Nedir API Testi ?

API testi, API'ye ├ža─čr─▒lar g├Ândermek ve verimi almak i├žin programlamadan yararlan─▒r. Test, test edilen segmenti kara kutu olarak g├Âr├╝r. API testinin amac─▒, bir uygulamaya koordine edilmesinden ├Ânce par├žan─▒n do─čru ┼čekilde uygulanmas─▒n─▒ ve hata ay─▒klamas─▒n─▒ onaylamakt─▒r.

REST API

REST: Temsili Durum Transferi.

  • Test uzmanlar─▒n─▒n istekleri yerine getirdi─či ve yan─▒t ald─▒─č─▒ i┼člevlerin bir d├╝zenlemesidir. REST API'sinde etkile┼čimler HTTP protokol├╝ ile yap─▒l─▒r.
  • REST ayr─▒ca, bilgisayarlar aras─▒nda birbirleriyle a─č ├╝zerinden ileti┼čime izin verir.
  • Mesaj g├Ânderip almak i├žin HTTP y├Ântemlerini kullanmay─▒ i├žerir ve Web servislerinin aksine kat─▒ bir mesaj tan─▒mlamas─▒ gerektirmez.
  • REST mesajlar─▒ genellikle formu XML veya JavaScript Nesne Notasyonu (JSON) ┼čeklinde kabul eder.

4 Yayg─▒n Olarak Kullan─▒lan API Y├Ântemleri: -

  1. GET: - Bir kayna─ča salt okunur eri┼čim sa─člar.
  2. POST: - Yeni bir kaynak olu┼čturmak veya g├╝ncellemek i├žin kullan─▒l─▒r.
  3. PUT: - Mevcut bir kayna─č─▒ g├╝ncellemek veya de─či┼čtirmek ya da yeni bir kaynak olu┼čturmak i├žin kullan─▒l─▒r.
  4. S─░L: - Bir kayna─č─▒ kald─▒rmak i├žin kullan─▒l─▒r.

API'yi Manuel Olarak Test Etme Ad─▒mlar─▒: -

API'yi manuel olarak kullanmak i├žin taray─▒c─▒ tabanl─▒ REST API eklentilerini kullanabiliriz.

  1. POSTMAN (Chrome) / REST (Firefox) eklentisini y├╝kleyin
  2. API URLÔÇÖsini girin
  3. REST y├Ântemini se├žin
  4. ─░├žerik Ba┼čl─▒─č─▒ Se├ž
  5. JSON ─░ste─čini Girin (POST)
  6. G├Ânder t─▒klay─▒n
  7. ├ç─▒kt─▒ tepkisi d├Ând├╝r├╝r

REST API'sini Otomatikle┼čtirme Ad─▒mlar─▒


5







Bu, her yerde ├žok daha az s├Âz edilmektedir, ancak Richardson'un Olgunluk Modeli , Ki┼činin API'sinin ne kadar Restful oldu─čunu yarg─▒laman─▒n en iyi y├Ântemlerinden biridir. Burada daha fazlas─▒:

Richardson Olgunluk Modeli


5







REST'i anlamada ├Ânemli bir yap─▒ ta┼č─▒n─▒n son noktalarda veya haritalarda oldu─ču gibi oldu─čunu s├Âyleyebilirim /customers/{id}/balance .

B├Âyle bir son noktay─▒ web sitesinden (├Ân u├ž) veri taban─▒n─▒za / sunucunuza (arka u├ž) ba─člant─▒ hatt─▒ olarak hayal edebilirsiniz. Bunlar─▒ kullanarak, ├Ân u├ž, uygulaman─▒zdaki herhangi bir REST e┼člemesinin kar┼č─▒l─▒k gelen y├Ântemlerinde tan─▒mlanan arka u├ž i┼člemleri ger├žekle┼čtirebilir.


2