32 Soru: RESTful programlama tam olarak nedir?

tarafından oluşturulan soru Thu, Mar 16, 2017 12:00 AM

RESTful programlama tam olarak nedir?

    
3856
  1. aşağıdaki bağlantıya verilen cevaba da bakın stackoverflow.com/a/37683965 /3762855
    2016-06-07 19: 59: 49Z
  2. REST şimdi biraz yaşlanıyor olabilir;) youtu.be /WQLzZf34FJ8
    2016-07-16 01: 50: 38Z
  3. Ayrıca, daha fazla bilgi için bu bağlantıya bakın news.ycombinator.com/item?id=3538585
    2017-02-18 12: 38: 56Z
  4. 2017-08-25 07: 11: 57Z
  5. @ OLIVER.KOO güzel gözlem. Sadece yeni bir şey olduğu bir zamanda sordum. Etrafa çok atılıyordu ama ne olduğunu bilmiyordu. En azından ben yapmadım ve sanırım bunu sormak onlara yardım etti çünkü onlar da bilmek istiyorlardı.
    2018-02-26 03: 18: 30Z
30 Yanıtlar                              30                         

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

REST taraftarları,

gibi URL’leri tercih etme eğilimindedir.  
http://myserver.com/catalog/item/1729

ancak REST mimarisi bu "güzel URL’leri" gerektirmez.

parametresiyle bir GET isteği  
http://myserver.com/catalog?item=1729

her bit RESTful olarak bulunur.

GET isteklerinin hiçbir zaman bilgileri güncellemek için kullanılmaması gerektiğini unutmayın. Örneğin, bir sepete öğe eklemek için bir GET isteği

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

uygun olmaz. 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 verilmesi, ü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 istekleri payına ihtiyaç duyar.

Bu, Core JavaServer'ın karşılaştığı mükemmel kitaptan David M. Geary'nin kitabından alınmıştır.

    
669
2018-03-27 09: 14: 52Z
  1. Kullanılabilir Hatalı İşlemleri Liteleme: GET (Safe), PUT & DELETE (Bu bağlantıdaki restapitutorial.com/lessons/idempotency.html adresinde istisna belirtilmiştir). Güvenli ve Ek Bilgiler Idempotent Yöntemleri w3.org/Protocols/rfc2616 /RFC2616-sec9.html
    2015-07-21 04: 00: 20Z
  2. a) GET ile ilgili önemli nokta, kesinlik değil, güvenirliktir, b) @Abhijeet: RFC 2616, 2014'te kullanılmıyor; bkz. RF 7230ff.
    2016-05-06 06: 16: 03Z
  3. 2017-08-25 07: 09: 35Z
  4. @ kushalvm REST'in akademik tanımı pratikte kullanılmıyor.
    2017-08-27 15: 31: 14Z
  5. Etkili bir kavramın işe yarayıp yaramadığını merak edebiliriz çünkü basit olamadığımız için herkes için istikrarlı ve anlaşılır bir tanım sağlar
    2018-05-03 23: 03: 30Z

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, HTML olduğu ortam üzerinde hemfikir olması gerektiğidir.

REST ilkelerine uygun bir API, müşterinin 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ğlanmıştır. (Bu ilke HATEOAS : Uygulama Durumunun Motoru Olarak Hypermedia .)

Öyleyse, bu HTTP için nasıl uygulanır ve pratikte nasıl uygulanabilir? HTTP, fiiller ve kaynaklar etrafında yönlendirilir. Yaygın kullanımdaki iki fiil, herkesin tanıyacağını düşündüğüm GET ve POST. Ancak, HTTP standardı, PUT ve DELETE gibi başkalarını da 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. Servisimiz, application/json+userdb mimetilini atadığımız JSON'a dayanan özel bir hiper medya kullanıyor (application/xml+userdb ve application/whatever+userdb da 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 'in işaret ettiği gibi:

  

Bir REST API’sının tanımlayıcı çabasının neredeyse tümünü   kaynakları temsil etmek ve araç kullanmak için kullanılan ortam türlerini tanımlamak   uygulama durumu veya genişletilmiş ilişki adları ve /veya tanımında   Mevcut standart ortam türleri için köprü metni etkin işaretleme.

/ temel kaynağa yönelik bir istek, bunun gibi bir şey döndürür:

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

Medyamızın tanımından, ilgili kaynaklar hakkında "bağlantılar" bölümlerinden bilgi bulabileceğimizi biliyoruz. Buna Hypermedia denetimleri denir. Bu durumda, /user için başka bir istek yaparak kullanıcı listesini bulabileceğimiz bir bölümden bahsedebiliriz:

İ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 yanıttan çok şey söyleyebiliriz. Örneğin, POST'a kadar /user'a kadar yeni bir kullanıcı oluşturabileceğimizi biliyoruz:

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

Var olan verileri değiştirebileceğimizi de biliyoruz:

Rearayışı

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

Bu kaynakları işlemek için farklı HTTP fiilleri (GET, PUT, POST, DELETE vb.) kullandığımızı ve müşterinin kendi tarafında düşündüğümüz tek bilginin medya tanımımız olduğunu fark edin.

Daha fazla okuma:

(Bu cevap, noktayı kaçırmak için adil bir eleştiriye konu olmuştur. Çoğunlukla, adil bir eleştiri olmuştur. İlk olarak tarif ettiğim şey, REST'in genellikle birkaç yıl içinde nasıl uygulandığına paralel olarak daha fazla açıklamıştı. önce gerçek anlamı yerine, bunu ilk yazdığımda, gerçek anlamı daha iyi temsil etmek için cevabı değiştirdim.)

    
2877
2019-04-10 15: 31: 47Z
  1. Hayır. REST sadece başka bir buzzword olarak ortaya çıkmadı. SOAP tabanlı veri alışverişine bir alternatif tanımlamanın bir aracı olarak ortaya çıktı. REST terimi, verilerin nasıl aktarılacağı ve erişileceği hakkındaki tartışmanın çerçevelemesine yardımcı olur.
    2009-03-22 15: 11: 52Z
  2. Bununla birlikte, REST'in kalbi (pratik uygulamada) "değişiklik yapmak için GET kullanmayın, POST /PUT /DELETE kullanın", ki bu tavsiye '' SOAP görünmeden çok uzun zamandır işitiyor ve takip ediyor. REST her zaman oradaydı, yakın zamana kadar "yapma yolunun" ötesinde bir ad almadı.
    2009-03-22 15: 16: 54Z
  3. Unutma "Uygulama durumunun motoru olarak köprü" ".
    2009-03-22 15: 54: 39Z
  4. Bu cevap, noktayı özlüyor. HTTP, Fielding'in tezinde çok az bahsedilir.
    2010-11-18 02: 22: 49Z
  5. Bu cevap REST'in amacından bahsetmiyor ve hepsi temiz URI'lar gibi görünüyor. Bu, REST'in popüler algısı olsa da, D.Shawley ve çocuklarının cevapları daha doğrudur - bu, önbellekleme yerine, onunla birlikte çalışarak mimaride yerleşik özelliklerden faydalanabilmektir. Daha güzel URI'ler çoğunlukla yaygın bir yan etkidir.
    2010-12-20 20: 49: 03Z

RESTful programlama hakkında:

  • Kaynaklar kalıcı bir tanımlayıcı tarafından tanımlanıyor: URI'lar bu günlerde her yerde bulunan tanımlayıcı tercihidir
  • Kaynaklar, ortak bir fiil seti kullanılarak manipüle edilir: HTTP yöntemleri, yaygın olarak görülen durumdur - saygıdeğer Create, Retrieve, Update, Delete, POST, GET, PUT ve DELETE olur. 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 kaynağı temsil eden bir Java Nesnesi isteyip istemediğinizi kontrol etmek için Kabul başlıklarını kullanın
  • devleti nesnede tutmak ve temsilde devleti temsil etmek
  • , kaynak temsilindeki 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 koşullar altında tutarlı bir şekilde atılması /yenilenmesi gerektiğini açıklar: HTTP Önbellek Kontrolü başlıklarının kullanımı

Sonuncusu, REST'in sonuçları ve genel etkinliği bakımı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 o terimi tarif ettiği zaman terim yazdığını anlıyorum.e HTTP'ye götüren mimari ve kararlar. Tezi, kaynakların mimarisi ve önbellek yeteneği hakkında HTTP'dekinden daha fazladır.

RESTful bir mimarinin ne olduğu ve neden çalıştığıyla gerçekten ilgileniyorsanız, oku! Daha sonra DNS'nin neden işe yaradığını inceleyin. 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 özelliklerini okuyun ( RFC2616 ve özellikle RFC3040 ) ve önbelleğe alma işleminin nasıl çalıştığını ve neden çalıştığını dikkate alın. 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.

Bir RESTful ve PUT kullanılabilir. POST, sunucu yeni URI'yi atadığında oluşturuyor.

2012-02-01 23: 30: 14Z
  • PATCH'ı unutma.
    2013-09-16 15: 20: 27Z
  • Bir URN, urn: şemasını kullanan bir URI'dir. Kavramsal olarak hiçbir fark yoktur; ancak, bir URN, URN tarafından tanımlanan (adlandırılmış) kaynağı "bulmak" için ayrı olarak tanımlanmış bir yönteminizin olmasını gerektirir. Adlandırılmış kaynakları ve konumlarını ilişkilendirirken örtük kuplaj kullanmamaya özen gösterin.
    2014-03-30 14: 45: 37Z
  • @ ellisbben Kabul edildi. Doğru anlarsam, bu REST'e yol açan tezdir: ics .uci.edu /~ Fielding /pub /tez /rest_arch_style.htm
    2014-09-10 12: 56: 12Z
  • Görünüşü bu olabilir.

    Üç özellikli bir kullanıcı oluşturun:

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

    Sunucu yanıt veriyor:

     
    200 OK
    Location: /user/123
    

    Gelecekte, kullanıcı bilgisini alabilirsiniz:

     
    GET /user/123
    

    Sunucu yanıt veriyor:

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

    Kaydı değiştirmek için (lname ve age aynı 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
    
        
    404
    2017-02-06 20: 23: 38Z
    1. Benim için bu cevap istenen cevabın özünü açıkladı. Basit ve pragmatik. Çok sayıda başka kriter var, ancak verilen örnek harika bir lansman pedi.
      2012-02-01 22: 09: 41Z
    2. Son örnekte, @pbreitenbach PUT fname=Jonny kullanıyor. Bu, lname ve age’u varsayılan değerlere (muhtemelen NULL veya boş dize ve 0 tamsayısı) ayarlayacaktır, çünkübir PUT, verilen sunumdan elde edilen verilerle tüm kaynağın üzerine yazar . Bu, "güncelleme", gerçek bir güncelleme yapmak için ima edilmez, PATCH yöntemini kullanın çünkü gösterimde belirtilmeyen alanları değiştirmez.
      2013-01-31 09: 43: 18Z
    3. Nicholas haklı. Ayrıca, bir kullanıcı oluşturan ilk POST için URI kullanıcı olarak adlandırılmalıdır, çünkü /user/1 hiçbir anlam ifade etmemektedir ve /users'da bir liste olması gerekir. Yanıt bir 201 Created olmalı ve bu durumda sadece Tamam değil.
      2013-02-16 19: 58: 38Z
    4. Bu sadece mutlaka bir RESTful api değil, bir API örneğidir. Bir RESTful uyması gereken kısıtlamaları vardır. İstemci-Sunucu Mimarisi, Vatansızlık, Önbellek yeteneği, Katmanlı Sistem, Düzgün Arabirim.
      2018-06-26 22: 11: 08Z
    5. Bu, tüm http servlet erişim yöntemlerini kapsayan çok küçük bir yanıt.
      2019-01-03 19: 45: 21Z

    REST hakkında harika bir kitap: Pratikte REST .

    Okunması gerekenler Temsili Durum Transferi (REST) ​​ olmalıdır. ve REST API’leri köprü metinli olmalı /p>

    Ne RESTful hakkında bir açıklama için Martin Fowlers makalesine bakın, Richardson Olgunluk Modeli (RMM) Servis

    Richardson Olgunluk Modeli

    RESTful Olmak için bir Hizmetin Hypermedia'ı Uygulama Durumu Motoru olarak yerine getirmesi gerekir. (HATEOAS) , yani RMM’de 3. seviyeye ulaşması gerekiyor, makaleyi okuyun ayrıntılar için veya qcon konuşmasından slaytlar .

      

    HATEOAS kısıtlaması bir kısaltmadır   Hypermedia için Motor olarak   Başvuru Durumu Bu ilke   REST arasındaki anahtar farkatör   ve diğer birçok istemci sunucusu   sistemi.

         

    ...

         

    RESTful bir uygulama ihtiyacı olan bir müşteri   erişmek için yalnızca tek bir sabit URL bilin   o. Gelecekteki tüm eylemler olmalıdır   dinamik olarak keşfedilebilir   dahil edilen hypermedia bağlantıları   Kaynakların temsili   bu URL’den döndürülür.   Standart medya türleri de   herhangi biri tarafından anlaşılması bekleniyor   RESTful API kullanabilecek bir istemci.   (Vikipedi, özgür ansiklopedi)

    Web Altyapıları için REST Litmus Testi benzer bir vadedir. web çerçevelerini sınayın.

    Saf REST'e yaklaşma: HATEOAS'ı sevmeyi öğrenme , iyi bir bağlantı koleksiyonudur.

    için SOAP REST Genel Bulut mevcut REST kullanım seviyelerini tartışıyor.

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

        
    178
    2013-09-08 17: 43: 09Z
    1. Bu cevabın REST anlayışının anahtar noktasına değdiğini düşünüyorum: temsili kelimesinin anlamı nedir. Seviye 1 - Kaynaklar eyalet hakkında diyor. Seviye 2 - HTTP Fiilleri transfer hakkında ( değişiklik okuyun) der. Seviye 3 - HATEOAS, gelecekteki transferleri temsil yoluyla (JSON /XML /HTML iade edildi) yönlendirdiğini söylüyor; bu, geri gönderilen bilgilerle bir sonraki konuşma turunu nasıl söyleyeceğinizi bildiğiniz anlamına geliyor.Böylece REST okur: "((temsil durumu) aktarımı) yerine" (temsil (devlet aktarımı))) ".
      2014-12-09 19: 49: 34Z
    2. 2018-02-08 22: 41: 37Z
      

    REST nedir?

         

    REST, Temsili Durum Transferi anlamına gelir. (Bazen   yazıldığından "ReST".) Bu vatansız, istemci-sunucu, önbelleğe dayanıyor   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.   Fikir, CORBA gibi karmaşık mekanizmalar kullanmak yerine,   Makineler arasında bağlanmak için RPC veya SOAP, basit HTTP yapmak için 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. Bu nedenle, REST dört CRUD için de HTTP kullanıyor   (Oluştur /Oku /Güncelle /Sil) işlemleri.

         

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

         

    Basit olmasına rağmen, REST tam özelliklidir; temelde var   RESTful ile yapılamayan Web Servislerinde yapabileceğiniz hiçbir şey   mimari. REST "standart" değildir. 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 dillerinde standart kütüphane özellikleriyle kendi dilinizi kullanın   Perl, Java veya C #.

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

    http://rest.elkstein.org/

        
    133
    2013-10-28 23: 07: 52Z
    1. Bu gerçekten özlü bir cevaptır. REST'in neden vatansız olmadığını da açıklayabilir misiniz?
      2019-02-12 17: 15: 49Z

    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üzenlemek için, /user/[id]’a GET isteği gönderdiğiniz bir kullanıcıdan bilgi almak için p>

    Ö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 sahip oldunuz ..

     
    GET /user/2
    DELETE /user/2
    PUT /user
    
        
    88
    2009-03-22 15: 20: 09Z
    1. "Huzurlu" ile aynı olmayan (bununla ilişkili olmasına rağmen) "HTTP’yi düzgün kullanmak"
      2009-03-22 15: 56: 25Z
    2. Ayrıca /user /del /2 ve /user /remove /2 veya ... 'i de kullanabilirsiniz ... GET /DELETE /PUT /POST sadece standartlaştırılmış, "uygun "böyle şeyler yapmanın yolu (ve Julian’ın dediği gibi, hepsi REST’te değildir)
      2009-06-02 21: 32: 20Z
    3. Tabi, ama onlardan kaçınmak için bir sebep yok. REST her seferinde tekerleği yeniden icat etmekten kurtarıyor. Bir API için, REST harikadır (tutarlılık!), Ancak rastgele bir web sitesi yapılandırmak için gerçekten önemli olduğunu söylemiyorum (değerinden daha fazla güç olabilir)
      2009-06-03 22: 34: 09Z
    4. Vadim, bu sadece RPC olurdu. Verileri değiştirmek için GET'i kullanmak da tehlikelidir, çünkü (diğer nedenlerin yanı sıra) bir arama motoru, silme bağlantılarınızı örter ve hepsini ziyaret eder.
      2009-07-20 17: 35: 20Z
    5. @ aehlke - Bence asıl soru "Neden adsız bir kullanıcı sisteminizden kayıtları silme yeteneğine sahip?" diye düşünüyorum.
      2014-12-03 05: 28: 19Z

    Sisteminizin mimarisinin REST tarzı Roy Fielding tarafından tezi 'de ortaya kondu. Bu, web'i (az ya da çok) tanımlayan mimari tarz olduğundan, pek çok insan onunla ilgilenmektedir.

    Bonus cevabı: Hayır. Yazılım mimarisini akademik ya da web tasarımı olarak okuyorsanız, terimi duymak için hiçbir neden yoktur.

        
    67
    2009-03-22 15: 56: 19Z
    1. ancak yalındır değil .. olması gerekenden daha karmaşık hale getirir.
      2009-03-22 15: 38: 08Z
    2. Ayrıca, REST ve RESTful terimleri neredeyse yalnızca web uygulamaları alanında kullanılsa da, teknik olarak REST'i HTTP'ye bağlayan hiçbir şey yoktur.
      2009-03-22 15: 52: 50Z
    3. Fielding'in blogu, REST ve yaygın kavram yanılgılarıyla ilgili makaleleri anlamak için iyi, daha kolay: roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
      2009-07-20 17: 32: 53Z
    4. @ HankGay Daha ezoterik olmama sebebinin çoğu web servis geliştiricisinin REST'i SOAP gibi alternatifler üzerinde harika bir basitleştirme olarak görmesi olduğunu düşünüyorum. Tüm REST tekniklerinin doğru olmasına kesinlikle bağlı kalmazlar - ve bu muhtemelen REST fanatiklerini çılgına çevirir - ancak çoğu durumda, sonuçlarının "hypermedia-etkin" olduğundan emin olmak gibi şeyler için endişelenmeleri gerekmez.
      2013-07-04 11: 56: 12Z

      Soruyu doğrudan yanıtlayamadığım için ö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çıklama: Spam Temizleme Robotunu Spam-E Spam p>

      Daha da iyisi, burada basit örneklerle temiz bir açıklama var (powerpoint daha kapsamlı, ancak çoğunu html sürümünde alabilirsiniz):

      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çekte 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 bildiği için, bunun bana karşı konulmadığı açık değildir.

      Bu xfront belgesi REST ve SOAP arasındaki farkı açıklar ve bu da gerçekten yardımcı olur. Fielding derken, " RPC'dir. ", RPC’nin RESTful olmadığı açık olduğundan, bunun nedenlerini tam olarak görmek faydalıdır. (SOAP bir RPC türüdür.)

          
      45
      2017-09-06 20: 26: 46Z
      1. harika linkler, teşekkürler. Bazı örneklerin "REST-ful" olmadığını söyleyen REST adamlarından bıktım, sonra refu.Örneği REST-ful olarak nasıl değiştireceğinizi söyleyin.
        2012-02-01 19: 19: 02Z

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

      Dr. M. Elkstein'ın REST hakkındaki öğreticisini anlatan bu fantastik, kısa ve anlaşılması kolay olan ve çoğunlukla sorunuzu cevaplayabilecek önemli kısmı belirten buldum:

      REST Öğrenin: Bir Öğretici

        

      REST, ağ uygulamaları oluşturmak için mimari stildir .   Fikir, CORBA gibi karmaşık mekanizmalar kullanmak yerine,   Makineler arasında bağlanmak için RPC veya SOAP, basit HTTP yapmak için kullanılır   makineler arasında aramalar.

           
      • Birçok yönden, HTTP tabanlı World Wide Web'in kendisi REST tabanlı bir mimari olarak görüntülenebilir.
      •   

      RESTful uygulamalar veri göndermek için HTTP isteklerini kullanır (oluştur ve /veya   güncelleme), veri okuma (örneğin, sorgulama yapma) ve verileri silme. 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 şey duymadığın için aptal hissetmemelisin bence ... aynı durumda olurdum !; Bu diğer SO sorununun yanıtları REST neden şimdi büyüyor? bazı duyguları kolaylaştırabilir.

          
      45
      2019-02-14 16: 55: 02Z

      REST nedir?

      Resmi kelimelerle REST, REST, mevcut “Web” esaslarını kullanarak belirli ilkelere dayanan mimari bir stildir. REST hizmetleri oluşturmak için kullanılan web temelleri 5 temeldir.

      • İ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.
      • 2. İlke: Her Kaynak Benzersiz Bir Tanımlayıcı (URI) ile Tanımlanır
      • İlke 3: Basit ve Düzgün Arayüzler Kullanın
      • 4. İlke: İletişim, Temsil ile Yapılıyor
      • 5. İlke: Vatansız Olma
      38
      2014-07-31 17: 11: 49Z
      1. Communication is Done by Representation ne anlama geliyor?
        2019-03-10 21: 59: 38Z

      Kullanıcı 123 hakkındaki her şeyi "/user /123" kaynağına koymanın RESTful olduğunu söyleyen birçok yanıt görüyorum.

      Bu terimi oluşturan Roy Fielding, REST API'lerin köprü metni tarafından yönlendirilmesi gerekiyor . Özellikle, "Bir REST API'si sabit kaynak adlarını veya hiyerarşilerini tanımlamamalıdır".

      "/user /123" yolunuz istemcide kodlanmışsa, 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 16: 36: 31Z
      1. yani .... bu örnek nasıl dinlendirici olurdu? URL’yi dinlendirici yapmak için nasıl değiştirirsiniz?
        2009-03-22 16: 49: 09Z
      2. hasen: Tüm işlemler için bir kaynak kullanmak, RESTfulness için gerekli olabilir, ancak yeterli değil .
        2009-03-22 17: 20: 17Z
      3. tamam iyi .. daha fazla açıklayabilir misiniz? "Bu adamlar yanlış değil .. doğru olanı biliyorum" demenin anlamı ne doğru olduğunu bildiğini (veya ne düşündüğünü) söylemeden?
        2009-03-22 20: 55: 14Z
      4. , Fielding'in açıklamasına link verdim. Diğer cevaplara tam olarak karşılık gelen farkı söylediğimi sanıyordum: köprü metni tarafından yönlendirilmesi gerekiyor." /User /123 "bant dışı bir API dokümantasyonundan geliyorsa, o zaman RESTful değildir. Köprü metninizdeki bir kaynak tanımlayıcısından geliyorsa, öyleyse öyledir.
        2009-03-23 ​​02: 08: 07Z
      5. Veya /users /gibi bir giriş noktası kullanabilirsiniz ve her biri için kullanıcı kaynakları ve URI listelerini verecektir. Ardından kaynaklar keşfedilebilir ve gezinti köprü metni güdümlü.
        2009-07-20 17: 37: 18Z

      Cevap çok basit, bir tez çalışması var > Roy Fielding tarafından yazılmıştır.] 1 Bu tezde REST ilkelerini tanımlar. Bir uygulama bu ilkeleri yerine getirirse, bu bir REST uygulamasıdır.

      RESTful terimi, ppl sözcüğünü tükettiği için oluşturuldu REST dışı uygulamalarını REST olarak çağırarak REST. Bundan sonra RESTful terimi de tükenmişti. Bugünlerde Web API'lerinden ve Hypermedia API'lerinden bahsediyoruz , çünkü REST uygulamalarının çoğu tek tip arayüz kısıtlamasının HATEOAS bölümünü yerine getirmedi.

      REST kısıtlamaları aşağıdaki gibidir:

      1. istemci-sunucu mimarisi

        Dolayısıyla, ö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 uygulamalarda birçok oturumu sürdürmek zordur.)

      3. mümkünse önbellek kullanımı

        Böylece aynı istekleri tekrar tekrar yerine getirmeniz gerekmez.

      4. istemci ile sunucu arasındaki 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 istemci, geçerli 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 etmelidir. Bağlantıları kontrol ederek, http://schema.org/OrderAction ile açıklandığı bulundu. 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 sonucu, örneğin 201 - created cevap verir. Bir RDF formatı kullanmak için standart çözüm içeren ayrıntılı meta veri mesajlarına açıklama eklemek için, örneğin bir REST kelimesiyle JSON-LD , örneğin Hydra ve schema.org veya başka bir bağlantılı veri kelimesi ve gerekirse belki özel bir uygulamaya özel kelime. Şimdi bu kolay değil, ppl'nin çoğunun HAL ve diğer basit formatları kullanması, genellikle yalnızca REST kelimesi sağlıyor, fakat bağlantılı veri desteği yok.

      5. ölçeklenebilirliği artırmak için katmanlı bir sistem oluşturun

        REST sistemi hiyerarşik katmanlardan oluşur. Each katmanı, bir sonraki katmanda bulunan bileşenlerin hizmetlerini kullanan bileşenler içerir. Böylece zahmetsizce yeni katmanlar ve bileşenler ekleyebilirsiniz.

        Örneğin, müşterileri 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. müşteri 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ı, müşterilerin 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
      2014-09-19 01: 30: 46Z

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

      1. Kaynak (veri, bilgi).
      2. Benzersiz genel tanımlayıcı (tüm kaynaklar URI ).
      3. Tek tip arayüz - basit ve standart arayüz kullanın (HTTP).
      4. Temsil - tüm iletişim temsil ile yapılır (örneğin, XML /JSON )
      5. Stateless (her istek tamamen yalıtılmış bir durumda gerçekleşir, önbelleklenmesi ve yük dengesi daha kolaydır),

      Başka bir deyişle, her bir "kaynağın" ortaya çıkardığı arabirimin 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 .

      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
      2014-06-15 19: 08: 26Z

      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’lerle isteniyor.
      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, tezde HTTP POST, GET, DELETE veya PUT işlemlerinden söz edilmez. Bu birinin la olmalı"homojen bir arayüz" için "en iyi uygulama" terimlerinin yorumlanması.

      Web hizmetleri söz konusu olduğunda, arayüze önemli ölçüde ek ve tartışmasız bir şekilde karmaşıklık katan WSDL ve SOAP tabanlı mimarileri ayırt etmenin bir yoluna 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 olduğundan emin değilim. Fakat bir şeye ihtiyacımız var.

          
      17
      2012-02-01 17: 23: 09Z

      REST, mimari bir desen ve dağıtılmış uygulama yazma stilidir. 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. 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.

      REST, ev tarzlarının aksine, tutarlı ve pratik bir şekilde uygulanmakta zorlandı. Bu kasıtlı olabilir. Gerçek uygulamasını tasarımcıya bırakarak. Demek istediğin şeyi yapmakta özgürsün, tezinde belirtilen kısıtlamaları karşıladığın sürece REST Sistemlerini yaratırsın.

      Bonus:

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

          
      17
      2012-02-01 21: 20: 21Z

      İş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ğa bağlı kaynakların (yani, bilgi paylaşan düğümler) nasıl tasarlandığını ve ele alındığını ana hatlarıyla gösteren 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ı söyleyebilmesi 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 önceki istekler hakkında bir şey hatırlamak zorunda kalmaması (istemci-sunucu etkileşiminin önceki durumları) ) yeni bir talebe cevap vermek için. Bu, etkileşimlerimizin vatansız olmasını istediğimiz anlamına geliyor.

      • Son zamanlarda belirli bir müşteri için yapılmış olan hesaplamaları yeniden yapmaktan sunucumuzun zorlamasını daha da azaltmak için, REST ö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üresi dolmamışsa - sunucu bir son kullanma süresi belirler.advance - ve ilk önbellekten bu yana yanıt güncellendi (yani istek önbelleğe alınan yanıttan farklı bir cevap verecekti), istemci önbellek sona erinceye kadar (veya önbellek temizlenene kadar) güncellemeleri görmeyecek ve yanıt yeniden sıfırdan oluşturuldu.

      • 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 tümü 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-04-14 01: 27: 55Z

      Huzursuzluğun, interneti (vatansız taşımacılık katmanı) olarak kullanırken, durumun durumluluğun 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ğındaki 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.

      Rahat bir stille, uygulamanın durumunu güvenilmez bir internet üzerinden alır ve 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üzenle: İki önemli yön daha:

      15
      2018-04-30 16: 18: 25Z
      1. A MVC bakış açısı: Blog En Kötü Uygulamaları Dinle , modelleri ve kaynakları bir araya getirmemeyi önerdi. = "http://twoscoopspress.org/products/two-scoops-of-django-1-6" rel = "nofollow noreferrer"> django’nun iki kepçe , Rest API’nın görünüşte olduğunu öne sürüyor İş mantığını görünüme karıştırmak için. Uygulamanın kodu uygulamanın içinde kalmalıdır.
        2015-06-25 06: 20: 37Z
      2. 2015-06-25 15: 14: 56Z

      Bu inanılmaz 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 ortak ve çok fazla bira olmadan dinlendirici programlama gibi bir şey yoktur :)

      2) Temsil Edici Devlet Transferi (REST) ​​ İşte bu.

      Kısıtlamaları (önemli ölçüde) şu şekilde özetleyebilirsiniz:

      • vatansız iletişim
      • HTTP özelliklerine saygı gösterin (HTTP kullanılıyorsa)
      • aktarılan içerik biçimlerini açıkça iletir
      • hypermedia'yı uygulama durumunun motoru olarak kullanın

      Başka bir çok iyi bir yayın var hangi şeyleri güzelce açıklıyor?

      Bir çok cevap, bilgiyi karıştırarak ve biraz karışıklık ekleyerek geçerli bilgileri kopyalar /yapıştırır. İnsanlar burada seviyelerden, RESTFul URI'lerden (böyle bir şey yoktur!) Bahsediyorlar, HTTP yöntemlerini uyguladıkları 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, aldığınız /gönderdiğiniz bağlantılarla gerçekten ilgilenmez, önemli olan içeriktir.

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

          
      14
      2017-01-24 10: 54: 26Z

      Eski soru, cevap vermenin newish tarzı. Dışarıda bu kavram hakkında bir çok yanlış anlaşılma var. Her zaman hatırlamaya çalışıyorum:

      1. Yapılandırılmış URL'ler ve Http Yöntemleri /Fiiller, tanımı değildir. dinlendirici programlama.
      2. JSON dinlendirici bir programlama değil
      3. RESTful programlama, API'ler için değildir

      Dinlendirici programlamayı

      olarak tanımlarım
        

      Bir uygulama, müşterinin anladığı bir medya türünde kaynaklar (veri + durum geçişleri kontrollerinin birleşimidir) sağlarsa rahattır

      Dinlendirici bir programcı olmak için, oyuncuların işleri yapmasına izin veren uygulamalar oluşturmaya çalışıyor olmalısınız. Yalnızca veritabanını göstermiyoruz.

      Durum geçişi kontrolleri yalnızca müşteri ve sunucu kaynağın medya türünü temsil etmesi konusunda anlaşırlarsa 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> etiketi bilmiyorlarsa, o zaman tarayıcınızdaki geçiş durumuna göndermeniz için hiçbir şey kalmayacaktı.

      Kendini 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ından kaynaklanıyor, seviyelere inanmıyorum, ya RESTful (seviye 3) ya da değilsin, ama bunun hakkında söylemek istediğim şey RESTful'a giderken her seviyenin senin için ne işi var

       açıklamalı richardson vade modeli

          
      12
      2019-02-28 09: 03: 54Z

      REST === "Zorunlu" olduğunu HATEOAS sürüldü.

      Roy kendisi burayı temizledi.

      Başlangıç ​​URI'sının (yer imi) ve önceden belirlenmiş hedef kitleye uygun (yani, API'yi kullanacak herhangi bir müşteri tarafından anlaşılması bekleniyor) ötesinde hiçbir bilgi olmadan bir REST API'si 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 (ö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
      2017-08-23 10: 00: 00Z
      1. soruyu diğerleri kadar iyi yanıtlamıyor, ancak ilgili bilgiler için +1!
        2017-10-02 19: 06: 25Z
      2. Bunun da soruyu yanıtladığını düşünüyorum, ancak örneğin vatansızlık ondan eksik. Her kısıtlama önemlidir ... Standart ortam türü kısmı her zaman doğru değildir. Yani anlama katmanları var. Örneğin, eğer RDF kullanıyorsanız, medya tipi anlaşılabilir, ancak içeriğin anlamı anlaşılamaz. Bu nedenle müşterinin kelimeleri de bilmesi gerekir. Bazı insanlar köprüler, vb. Tanımlamak için bu tür REST API'leri ve genel bir REST sözlüğü ile deneyler yapıyor. hydra-cg. com
        2018-12-08 08: 08: 31Z

      REST, herhangi bir web hizmetini yapan - gerçek bir RESTful API olan 6 mimari kısıtlamayı tanımlar.

      1. Üniforma arayüzü
      2. Müşteri – sunucusu
      3. Vatansız
      4. Önbelleğe alınabilir
      5. Katmanlı sistem
      6. Talep üzerine kod (isteğe bağlı)

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

          
      11
      2017-10-02 21: 23: 50Z
      1. Fielding eklendi bazı ek kurallar RESTful API'lerin /müşterilerin uyması gerekiyor
        2017-10-02 22: 09: 46Z
        

      REST , web 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 aracılığıyla erişilir.

        

      REST tabanlı bir mimaride, REST sunucusuna sahip olan ve   kaynaklara erişim. Bir REST istemcisi REST'e erişebilir ve bunları değiştirebilir.   kaynaklar.

      Her kaynak, HTTP ortak işlemlerini desteklemelidir. Kaynaklar genel kimlikler (genellikle URI'lar) tarafından 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ğa okuma erişimini tanımlar. Kaynak, örneğin bir GET isteği ile asla değiştirilmez., isteğin hiçbir yan etkisi yok (idempotent).
      • PUT yeni bir kaynak oluşturur. Ayrıca önemsiz olması gerekir.
      • 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
      2018-05-26 18: 08: 53Z
      1. Birkaç alıntı, ancak tek bir kaynak belirtilmedi. Bunu nereden aldın?
        2018-12-13 19: 02: 30Z

      REST , Temsili durum aktarımı 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.

      Dinlenmeye Giriş     

      10
      2014-11-10 13: 37: 27Z

      Konuşmak , basitçe bilgi alış verişinden daha fazladı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 olması 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 mimaridir . Fielding'in tezi, bir makinenin yalnızca iletişim kurmak yerine konuşmasına izin vermek istiyorsa, takip etmesi gereken mimariyi belirtir.     

      10
      2014-12-06 06: 54: 24Z

      Başlıca "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 :

        

      Bilgisayarda temsili durum aktarımı (REST) ​​bir   web geliştirme için kullanılan mimari stil.

          
      10
      2016-08-26 20: 35: 59Z

      Geri kalan nokta, temel işlemler için (http fiilleri) ortak bir dil kullanmayı kabul edersek, altyapının bunları anlayacak ve örneğin düzgün bir şekilde uygulamak için önbelleğe alma başlıklarından yararlanarak bunları en iyi duruma getirecek şekilde yapılandırılabilir olmasıdır. Her seviyede önbelleğe alma.

      Düzgün bir şekilde uygulanmış, dinlendirici bir GET işlemi ile, bilgilerin sunucunuzun DB'sinden, sunucunuzun memcache'sinden, CDN'den, 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.

      Dinlenme'nin 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ündüğü gibi tamamen kozmetiktir. Mesele, zincirin her parçası tarafından anlaşılabilecek ve optimize edilebilecek bir dil kullanmaktır. GET işleminizde yan etkileri olan bir işlem varsa, tüm HTTP önbelleğe almayı atlamanız gerekir, aksi takdirde tutarsız sonuçlarla sonuçlanırsınız.

      9
      2012-02-01 23: 52: 15Z
      1. "Dinlenmenin sadece sözdizimsel bir değişim olduğunu söylemek ... hiçbir yararı yokmuş gibi görünmesini sağlar ve tamamen kozmetiktir" --- tam olarak bu yüzden cevapları okuyorum burada SO. REST'in neden tamamen kozmetik olmadığını açıklamadığınızı unutmayın.
        2013-10-08 17: 14: 47Z

      API Test Etme nedir?

      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 yanlış muamele edilmesini 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ımı gerektirmez.
      • REST mesajları genellikle formu XML veya JavaScript Nesne Notasyonu (JSON) şeklinde kabul eder.

      4 Sık 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 (POST) İsteğini Girin
      6. Gönder'i tıklayın
      7. Çıktı yanıtını döndürür

      REST API'sini Otomatikleştirme Adımları

          
      5
      2016-08-01 12: 18: 53Z
      1. bu doğru bir cevap bile değil
        2016-08-05 07: 17: 26Z

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

      Richardson Olgunluk Modeli

          
      5
      2017-08-29 11: 55: 15Z
      1. REST'in getirdiği kısıtlamalara bakarsanız, bir API'nin RESTful olarak görülmesi için RMM'nin 3. Katmanına ulaşması gerektiğini açıkça göreceksiniz. bu aslında yeterli değil, çünkü REST fikrinin başarısız olması için yeterli imkan var - müşterilerin sunucu API'lerinden ayrılması. Tabii, Katman 3, HATEOAS sınırlamasını yerine getirir ancak gereksinimleri kırmak ve istemcileri bir sunucuya sıkıca bağlamak (örneğin, yazılan kaynakları kullanarak) hala kolaydır.
        2017-10-02 22: 21: 52Z

      REST'i anlamada önemli bir yapı taşının bitiş noktalarında veya /customers/{id}/balance gibi haritalarda olduğunu söyleyebilirim.

      Böylesi bir son noktanın web sitesinden (ön uç) veri tabanınıza /sunucunuza (arka uç) bağlantı hattı olduğunu hayal edebilirsiniz. Bunları kullanarak, ön uç arka uç operasyonu gerçekleştirebilirBaşvurunuzdaki herhangi bir REST eşlemesinin karşılık gelen yöntemlerinde tanımlanan rasyonlar.

          
      2
      2019-03-27 10: 11: 45Z
    kaynak yerleştirildi İşte