it-swarm-tr.com

RESTful programlama tam olarak nedir?

RESTful programlama tam olarak nedir?

3761
hasen

REST (Temsilsel Durum Aktarımı) - adlı bir mimari stil web uygulamalarının HTTP'yi başlangıçta öngörüldüğü gibi kullanması gerektiğini savunur. Aramalar GET request kullanmalıdır. PUT, POST ve DELETE istekleri , sırasıyla mutasyon, oluşturma ve silme için kullanılmalıdır.

REST taraftarları, URL’leri tercih etme eğilimindedir.

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 idempotent 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 isteklerinin payına ihtiyaç duyar.

Bu, David M. Geary'nin mükemmel kitabından Core JavaServer yüzleri kitabından alınmıştır.

619
Shirgill Farhan

REST, web'in temelindeki mimari ilkedir. 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, sunucunun ve istemcinin, HTML olduğu durumda kullanılan ortam üzerinde hemfikir olması gerektiğidir.

REST ilkelerine uygun bir API, istemcinin 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. 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ğlanmıştır. (Bu ilke olarak adlandırılır _ hateoas _ : Uygulama Durumunun Motoru Olarak Hypermedia .)

Peki, bu HTTP için nasıl geçerlidir ve pratikte nasıl uygulanabilir? HTTP fiiller ve kaynaklar etrafında yöneldi. Yaygın kullanımdaki iki fiil, herkesin tanıyacağını düşündüğüm GET ve POST. Ancak, HTTP standardı PUT ve DELETE gibi birkaç tanesini tanımlar. 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, application/json+userdb mimetipini atadığımız JSON'a dayanan özel bir hiper medya kullanıyor. (Bir application/xml+userdb ve application/whatever+userdb olabilir - birçok medya türü desteklenebilir). İstemci ve sunucu bu formatı anlayacak şekilde programlanmıştır, ancak birbirleri hakkında hiçbir şey bilmezler. --- Roy Fielding işaret ettiği gibi:

Bir REST API, kaynak göstermek ve uygulama durumunu desteklemek için kullanılan medya türlerini tanımlamak veya uygulama durumunu genişletmek için kullanılan medya türlerini tanımlamak veya genişletilmiş ilişki adları ve/veya köprü metni için etkin işaretleme tanımlamak için tanımlayıcı çabasının tamamını harcamalıdır. mevcut standart medya türleri.

/ ana kaynağı için bir istek, bunun gibi bir şey döndürebilir:

İstek

GET /
Accept: application/json+userdb

Yanıt

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 denir Hypermedia denetimleri . Bu durumda, böyle bir bölümden /user için başka bir istek yaparak kullanıcı listesini bulabileceğimizi söyleyebiliriz:

İstek

GET /user
Accept: application/json+userdb

Yanıt

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, şimdi POST ile /user ile yeni bir kullanıcı yaratabileceğimizi biliyoruz:

İstek

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

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

Yanıt

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

Yanıt

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

Bu kaynakları işlemek için farklı HTTP fiilleri (GET, PUT, POST, DELETE vb] kullandığımızı ve müşterinin tahmin ettiği tek bilgiyi kullandığımızı fark edin. bölüm bizim medya tanımımızdır.

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 tarif ettiğim şey, daha çok REST 'in nasıl uygulandığına paraleldi. birkaç yıl önce, ilk yazdığımda, gerçek anlamından ziyade, gerçek anlamını daha iyi temsil etmek için cevabı revize ettim.)

2886
Emil H

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.
  • ortak bir fiil seti kullanılarak manipüle edilen kaynaklar: HTTP yöntemleri yaygın olarak görülen durumdur - saygıdeğer Create, Retrieve, Update, Delete, POST, GET, PUT ve DELETE. Ancak REST HTTP ile sınırlı değil, şu anda en yaygın kullanılan ulaşım aracı.
  • 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 Nesne 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.

RESTful bir mimarinin ne olduğu ve neden çalıştığıyla gerçekten ilgileniyorsanız, tezini birkaç kez okuyun ve her şeyi okuyun sadece 5. Bölüm değil! Bir sonraki bakışta DNS neden çalışır . 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ı ( RFC2616 ve RFC304 özellikle) okuyun ve önbelleğe almanın nasıl çalıştığını nasıl ve neden çalıştığı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 Shared Nothing mimarilerinin mimari önemini ve performans etkilerini anlamadaki en önemli numara, teknoloji ve uygulama detaylarına takılmamaktan ibaret 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.

525
D.Shawley

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ı güncellemek için (ve dolayısıyla lname ve age NULL olacaktır):

PUT /user/123
fname=Johnny
401
pbreitenbach

REST hakkındaki harika bir kitap Pratikte REST .

Okunması gerekenler Temsili Durum Aktarımı (REST) ​​ ve REST API'leri köprü metni odaklı olmalıdır

RESTful hizmetinin ne olduğu hakkında bir açıklama için Martin Fowlers'ın Richardson Olgunluk Modeli (RMM) makalesine bakın.

Richardson Maturity Model

RESTful olmak için bir Hizmetin Uygulama Durumunun Motoru olarak Hypermedia'yı yerine getirmesi gerekir. (HATEOAS) , yani, RMM'deki 3. seviyeye ulaşması gerekir, ayrıntılar için makalesini veya slaytlarını oku qcon konuşması .

HATEOAS kısıtlaması, Uygulama Durumunun Motoru olarak Hypermedia için bir kısaltmadır. Bu ilke, REST ile diğer çoğu istemci sunucu sistemi biçimleri arasındaki kilit farktır.

...

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.

Herkese Açık Bulut için REST - SOAP _ , şu anki REST kullanım seviyesini tartışıyor.

REST ve sürüm oluşturma , Değiştirilebilirlik yoluyla Genişletilebilirlik, Sürüm Oluşturma, Evrimlilik, vb.

179
oluies

REST nedir?

REST, Temsili Devlet Transferi anlamına gelir. (Bazen '' ReST '' yazıldığından yazılır.) Vatansız, müşteri-sunucuya, önbelleklenebilir. iletişim protokolü - ve hemen hemen her durumda, HTTP protokol kullanılır.

REST, ağ bağlantılı uygulamaları tasarlamak için kullanılan bir mimari tarzdır. Buradaki fikir, CORBA, .__ gibi karmaşık mekanizmalar kullanmak yerine. Makineler arasında bağlantı kurmak için RPC veya SOAP, basit yapmak için HTTP kullanılır. makineler arasında aramalar.

Birçok yönden, HTTP'ye dayanan World Wide Web'in kendisi görüntülenebilir. REST tabanlı bir mimari olarak. RESTful uygulamalar, HTTP isteklerini kullanır. veri göndermek (oluşturmak ve/veya güncellemek), verileri okumak (örneğin, sorgu yapmak), ve verileri silin. Böylece, REST dört CRUD .__ için de HTTP kullanıyor. (Oluştur/Oku/Güncelle/Sil) işlemleri.

REST, RPC (Remote Prosedür Çağrıları) ve Web Servisleri (SOAP, WSDL ve diğerleri) gibi mekanizmalara hafif bir alternatiftir. Daha sonra yapacağız. REST 'in ne kadar basit olduğunu görün.

Basit olmasına rağmen, REST tam özellikli; temelde var. Web Servislerinde RESTful .__ ile yapılamayan hiçbir şey yapamazsınız. mimari. REST bir "standart" değil. Asla bir W3C .__ olmayacak. Örneğin, REST için öneri. Ve REST .__ varken. çerçeveleri programlama, REST ile çalışmak o kadar basittir ki genellikle kendi dillerini yuvarlayın "gibi dillerde standart kütüphane özellikleri ile. Perl, Java veya C #.

Dinlenmenin basit gerçek anlamını bulmaya çalışırken bulduğum en iyi referanslardan biri.

http://rest.elkstein.org/

132
Ravi

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 (örneğin, /user/123/delete), /user/[id] URL'sine bir DELETE isteği gönderir, bir kullanıcıyı düzenler, bir kullanıcı hakkında /user/[id] için GET isteği gönderir

Ö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
dbr

Sisteminizin mimarisinin REST tarzına / Roy Fielding'in tezi 'de ortaya koyduğu programlama. Bu, web'i (az ya da çok) tanımlayan mimari tarz olduğundan, pek çok insan onunla ilgilenmektedir.

Bonus cevap: Hayır. Yazılım mimarisini akademik olarak ya da web tasarımı tasarlayan bir işletme olarak çalışmadığınız sürece, bu terimi duymak için hiçbir neden yoktur.

67
Hank Gay

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 Hypertext'in Açıklaması: 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ü metin odaklı olduğunu 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şı konulmaz olduğu 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. " diye bağırıyor, RPC'nin RESTful olmadığı açık, bu yüzden bunun kesin nedenlerini görmek faydalı. (SOAP bir RPC türüdür.)

45
tompark

RESTful programlamanın REST mimari tarzını takip eden sistemler (API) oluşturmakla ilgili olacağını söyleyebilirim.

Dr. M. Elkstein tarafından REST hakkındaki fantastik, kısa ve kolay anlaşılır bir öğretici buldum ve sorunuzun çoğunu cevaplayacağınız önemli kısımdan alıntı yaptım:

REST Öğren: Bir Öğretici

REST, ağ uygulamaları oluşturmak için bir mimari tarzıdır. Buradaki fikir, CORBA, .__ gibi karmaşık mekanizmalar kullanmak yerine. Makineler arasında bağlantı kurmak için RPC veya SOAP, basit yapmak için HTTP kullanılır. makineler arasında aramalar.

  • 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 (HTTP oluşturmak ve/veya Güncellemek), veri okumak (örneğin sorgular yapmak) ve veri silmek için HTTP isteklerini kullanır. Böylece, REST Dört CRUD (Oluştur/Oku/Güncelle/Sil) işlemlerinin tümü için HTTP kullanır.

Yığın Taşması dışında REST hakkında bir şeyler duymadığın için kendini aptal hissetmen gerektiğini düşünmüyorum ... aynı durumda olurdum !; Bu diğer SO soruya cevaplar Neden REST şimdi büyüyor bazı duyguları rahatlatabilir.

44
Only You

REST nedir?

Resmi kelimelerle REST, REST, mevcut “Web” esaslarını kullanarak belirli ilkeler üzerine inşa edilmiş bir mimari tarzdır .. __ REST hizmetleri oluşturmak için kullanılan 5 temel web temeli 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şilebilir.
  • İlke 2: Her Kaynak Benzersiz Bir Tanımlayıcı (URI) ile Tanımlanır
  • İ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 
37
Suresh Gupta

"/ 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’lerin hipermete odaklı olması gerektiğini söylüyor. Özellikle, "A REST API sabit kaynak adlarını veya hiyerarşilerini tanımlamamalıdır".

Dolayısıyla, "/ 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.

34
Ken

Cevap çok basit, orada bir tez Roy Fielding tarafından yazılmış.] 1 Bu tezde REST ilkesini tanımlar. Eğer bir uygulama bu ilkeleri yerine getiriyorsa, bu bir REST uygulamasıdır.

RESTful terimi, ppl, REST olmayan uygulamalarını REST olarak çağırarak REST Kelimesini tükettiği için yaratıldı. Bundan sonra RESTful terimi de tükendi. Bugünlerde Web API'leri ve Hypermedia API'lerinden bahsediyoruz , çü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 vocabs, mesaj biçiminin farklı bölümlerinin anlamlarını tanımlamak için mikro biçimler, vb.). 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 vocabs) 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 tanımlanmış olanı bulur. 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 uygun gövdeyle bir POST https://example.com/api/v1/order mesajı gönderir. Bundan sonra servis mesajı işler ve uygun HTTP durum başlığına sahip olan sonuçla yanıt verir, örneğin başarı ile 201 - created. Ayrıntılı meta verilere sahip iletilere açıklama eklemek için, RDF biçimini kullanmak için standart çözümü kullanın; örneğin JSON-LD REST vocab ile, örneğin Hydra ve schema.org veya başka herhangi bir bağlantılı veri kelimesi ve belki de özel bir uygulamaya özgü kelime bilgisi gibi etki alanına özgü kelimeler. Şimdi bu kolay değil, ppl'nin çoğunun HAL ve genellikle basit bir REST kelimesi olan fakat bağlantılı veri desteği sağlamayan diğer basit formatları kullanmasının nedeni budur.

  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. i̇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 hizmetlerini bulabilen ve kullanan otomatik istemciler oluşturmayı 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
inf3rno

RESTful (Temsil halindeki devir) API programlama, 5 temel yazılımı mimari tarzı ilkeleri izleyerek, web uygulamalarını herhangi bir programlama dilinde yazıyor:

  1. Kaynak (veri, bilgi).
  2. Eşsiz global tanımlayıcı (tüm kaynaklar URI ile tanımlanmış benzersizdir).
  3. Düzgün arabirim - basit ve standart arabirim kullan (HTTP).
  4. Temsil - tüm iletişim temsil ile yapılır (örneğin XML / JSON )
  5. Vatansız (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.

20
kenorb

REST konusundaki orijinal tez çalışmasını sadece 3 kısa cümleye düşürmek zorunda olsaydım, aşağıdaki ö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 temelli mimarileri ayırmak 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, sağduyulu arabirimler ve WSDL ve SOAP gibi aşırı tasarlanmış 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
Nathan Andelin

İşte benim REST'in temel taslağı. Her bir bileşenin arkasındaki düşünceyi RESTful mimarisinde göstermeye çalıştım, böylece kavramı anlamak daha sezgiseldi. Umarım bu, bazı insanlar için REST 'in açığa çıkarılmasına yardımcı olur!

REST (Temsili Durum Aktarımı), ağ kaynaklı kaynakların (yani, bilgi paylaşan düğümler) nasıl tasarlandığını ve ele alındığını ana hatlarıyla 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 verilen herhangi bir kaynağı bulmak ve daha sonra 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, ayrıca 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 zorlanmayı daha önce belirli bir müşteri için yapılmış olan hesaplamaları yeniden yapmaktan daha da kolaylaştırmak için REST ayrıca önbelleklemeye 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ı yeniden yapmak yerine anlık görüntü sağlayabilir. Bununla birlikte, anlık görüntü olduğundan, anlık görüntü süresi dolmamışsa - 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) güncellemeleri göremez ve yanıt yeniden sıfırdan oluşturulur.

  • RESTful mimarileri hakkında sık sık burada olacağı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 soyut kavramının bir uygulamasıdır (ya da eğer bir REST ise OOP sınıfının bir örneğidir. benim gibi fanatik). 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
Kal

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

REST stilini kullandığınızı söylemek, belirli bir tarzda bir ev inşa ettiğinize benzer: Mesela Tudor veya Victoria. Bir yazılım stili olarak REST ve ev stili olarak Tudor veya Victoria, bunları oluşturan nitelikler ve kısıtlamalar ile tanımlanabilir. Örneğin, REST, iletilerin kendini tanımladığı İstemci 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. Böylece, tezde belirtilen kısıtlamaları karşıladığınız sürece, REST Sistemler oluştururken istediğinizi yapmakta özgürsünüz.

Bonus:

Webin tamamı REST 'e dayanıyor (veya REST web'e dayanıyor). Bu nedenle, bir web geliştiricisi olarak iyi web uygulamaları yazmak gerekmese de bunun farkında olmak isteyebilirsiniz. 

17
suing

Bence huzursuzun amacı durumsallığı daha yüksek bir katmana ayırırken, interneti (protokol) durumsuz taşıma katmanı . 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 uygulama 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
minghua

Bu şaşırtıcı derecede uzun bir "tartışma" ve henüz en azını söylemek oldukça kafa karıştırıcı.

IMO:

1) Büyük bir eklem ve çok fazla bira olmadan dinlendirici programlama gibi bir şey yoktur :)

2) Temsilsel Durum Transferi (REST), Roy Fielding'in bitirme tezi ..__'de belirtilen mimari bir stildir. 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 saygı gösterin (HTTP kullanılıyorsa)
  • iletilen içerik biçimlerini açıkça iletir
  • hypermedia'yı uygulama durumunun motoru olarak kullanabilir

Başka bir çok iyi mesaj var, bu da her şeyi güzelce açıklar.

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 linkler - güzel görünümlü bir API'ye sahip olmak güzeldir ancak sonunda müşteri/sunucu aldığınız/gönderdiğiniz linkleri gerçekten önemsemez. 

Sonunda, herhangi bir RESTful istemcisi, içerik formatı bilindiği sürece herhangi bir RESTful servisini kullanabilmelidir.

14
djodjo

REST === "Zorunlu" olduğunu HATEOAS sürdüğünü vurgulamadığınız sürece HTTP benzetmesi doğru değildir. 

Roy kendisi temizledi here .

Başlangıç ​​URI'sinin (yer imi) ötesindeki hiçbir ön bilgi olmadan bir REST API girilmeli ve hedef kitleye uygun (örneğin, API'yi kullanabilecek herhangi bir müşteri tarafından anlaşılması beklenen) bir dizi standartlaştırılmış medya türü belirtilmelidir. . 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 (örneğin, talep üzerine kod) medya türleri ve kaynak iletişim mekanizmaları hakkındaki bilgileri belirleyebilir (veya bunlarla sınırlı olabilir). 

[Buradaki başarısızlık, bant dışı bilgilerin köprü metni yerine etkileşimi sağladığını gösteriyor.]

11
lokesh

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
  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 (veri + durum geçişleri kontrollerinin birleşimidir) kaynaklar 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 tarayıcılar html’de <form> etiketlerini bilmiyorsa, 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

 annotated richardson maturity model

11
Chris DaMour

RESTweb standartlarına ve HTTP protokolüne dayalı (2000'de tanıtılan) mimari bir stildir.

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 üzerinden erişilir. 

REST tabanlı bir mimaride, .__ sağlayan bir REST sunucunuz var. kaynaklara erişim. Bir REST istemcisi REST .__ 'ya erişebilir ve bunları değiştirebilir. kaynaklar.

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 temsilci 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 yan etkisi yoktur (idempotent).
  • PUT yeni bir kaynak yaratır. Aynı zamanda önemsiz olmalı.
  • DELETE 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
Imran

REST, herhangi bir web servisi yapan 6 mimari kısıtlamayı tanımlar - bir gerçek 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/

10
Jaider

Konuşmak , 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şma RESTful mimarisidir. Fielding'in tezi, makinelerin basitçe iletişim kurmasından değil birbirleriyle konuşmasına izin vermek istiyorsa, izlenmesi gereken mimariyi belirtir. .

10
qmckinsey

REST, Temsili durum transferi anlamına gelir.

Vatansız, müşteri-sunucu, önbelleklenebilir iletişim protokolüne güveniyor - ve neredeyse her durumda, HTTP protokolü kullanılıyor.

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. Kaynakları (isimleri) kendi benzersiz evrensel kaynak göstergelerini (URI'leri) atayarak esneklik sağlanır. 

Dinlenme hakkında giriş

10
GowriShankar

Kendi başına "RESTful programlama" diye bir kavram yoktur. Daha iyi RESTful paradigması veya daha iyi RESTful mimarisi olarak adlandırılabilir. Bir programlama dili değil. Bu bir paradigmadır.

Wikipedia'dan :

Hesaplamada, temsili durum transferi (REST) ​​bir web geliştirme için kullanılan mimari stil.

10
ACV

Dinlenmenin amacı, temel işlemler (http fiilleri) için ortak bir dil kullanmayı kabul edersek, altyapının onları anlamak ve düzgün bir şekilde optimize etmek için, örneğin önbelleğe alma işlemini tümüyle uygulamak için önbellek başlıklarından yararlanarak yapılandırılabilir. 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şleminizin yan etkileri 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
Benoit Essiambre

Bu, her yerde çok daha az söz edilmektedir, ancak Richardson'un Olgunluk Modeli, bir kişinin API'sinin ne kadar Restful olduğunu yargılamanın en iyi yöntemlerinden biridir. Burada daha fazlası:

Richardson'un Olgunluk Modeli

5
kg11

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 uygulamada eşgüdümünden önceki kısmın doğru 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 'de API etkileşimleri 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

Otomatikleştirme Adımları REST API

5
kkashyap1707

REST kavramının anlaşılmasında önemli bir yapı taşının, /customers/{id}/balance gibi bitiş noktalarında ya da eşlemelerde yattığını söyleyebilirim.

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
Kürsat Aydinli

Bağlantılı kaynaklara örnekler veren bu cevaplar harika ancak resmin sadece yarısı.

Öyleyse, bir web sitesi tasarladığınızı hayal edin. Bir hikaye yaz

Gönderim adresi seçebilmem için posta koduyla bir adres arayabilmek istiyorum

Ardından, kullanıcıyı bu yolculuğa götürmek için bir site oluşturup sayfaları bir iş akışında birbirine bağlamayı denersiniz.

Onları bir adres aramasına götüren, ancak adresi panoya kopyalamak için bırakıp ardından gönderim adresi formuna geri döndüren bir web sitesi tasarımı çok kullanışlı olmaz.

Bir REST API, bir makine-makine etkileşimi için web'de aldığımız kalıpları kullanır.

Bir posta kodu özelliği araması base/addresses/{postcode} olmamalı ve her adres tam bir adrese ve bazı düzenleme bağlantılarına bağlansa bile, bir toplama geri dönüyor; API tüketicisinin adresin nasıl kullanılacağını tahmin etmesi gerekir.

Bunun yerine, özelliğin amacı, seyahatin başlangıcında sona ereceği şekilde kullanıldığı akışa yerleşik olmalıdır:

1 GET /orders/123/shipping

  200 OK { Current shipping details + link to parent + link to address picker }

2  -> GET /orders/123/shipping/addresspicker

      200 OK { Link and form for searching for a postcode }

3   -> GET /orders/123/shipping/addresspicker?postcode=tn11tl

       200 OK { List of addresses each with link to pick it }

4    -> POST /orders/123/shipping/addresspicker?postcode=tn11tl&pickNo=3

        200 OK { Current shipping details + link to parent + link to address picker }

Bu bir kullanıcı yolculuğu ve sonunda akışın sipariş üzerindeki etkisini görebilirsiniz.

HTTP isteği/yanıtı kesinlikle REST 'in bir parçası değil, ancak hiç kimsenin HTTP olmayan bir REST uygulaması gördüğünü sanmıyorum.

Şimdi bu URL'ler herhangi bir karakter kümesi olabilir, sadece tanımlayıcılar, onları güzelleştirdim çünkü insanlara mantıklı geliyorlar. Bir makine rel işlevini, ne okunabileceğini hesaplamak için kullanır, okunabilir bir href dosyasına bağlı olmaz.

0
Luke Puplett