Soru RESTful programlama tam olarak nedir?


RESTful programlama tam olarak nedir?


3630
2018-03-22 14:45


Menşei


ayrıca aşağıdaki bağlantıdaki cevaba bakınız stackoverflow.com/a/37683965/3762855 - Ciro Corvino
REST şimdi biraz eski olabilir;) youtu.be/WQLzZf34FJ8 - Vlady Veselinov
Ayrıca, daha fazla bilgi için bu bağlantıya bakın. news.ycombinator.com/item?id=3538585 - Ashraf.Shk786
Düzeltme yanıtları burada düzeltildi. stackoverflow.com/questions/19843480/...  Veya burada roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven  Veya burada web.archive.org/web/20130116005443/http://tomayko.com/writings/... - kushalvm
@ OLIVER.KOO güzel gözlem. Sadece yeni bir şey olduğu bir zamanda sordum. Çok fazla fırlatılıyordu ama pek çok kişi ne hakkında olduğunu bilmiyordu. En azından ben yapmadım, ve bunu sormamın onlara yardımcı olduğunu düşündüğü için onlara yardım ettiler. - hasen


Cevaplar:


bir mimari tarz denilen REST (Temsili Durum Transferi) web uygulamalarının HTTP'yi olduğu gibi kullanması gerektiğini savunur. aslen öngörülen. Aramalar kullanmalı GET istekleri. PUT, POST, ve DELETE istekler için kullanılmalıdır sırasıyla mutasyon, oluşturma ve silme.

REST destekçileri, URL’leri tercih etme eğilimindedir.

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

ancak REST mimarisi bu "güzel URL'leri" gerektirmez. Bir parametre ile bir GET isteği

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

RESTful olarak her şeydir.

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

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

uygun olmaz. GET istekleri olmalıdır idempotent. Yani, iki kez bir istek yayınlamak, bir kez yayınlamaktan farklı olmamalıdır. İstekleri önbelleğe alınabilir kılan budur. Bir "sepete ekle" isteği idempotent değildir; bu, öğenin iki kopyasını sepete iki kez ekler. Bu bağlamda bir POST talebi açıkça uygundur. Böylece, hatta RESTful web uygulaması POST isteklerinin paylaşımına ihtiyacı var.

Bu mükemmel kitaptan alınmıştır Temel JavaServer yüzleri David M. Geary kitabı.


541
2018-04-15 11:26



Lisiting Mevcut Idempotent İşlemleri: GET (Güvenli), PUT & DELETE (bu bağlantıda restapitutorial.com/lessons/idempotency.html adresinden istisna söz konusudur). Güvenli ve Idempotent Yöntemler için Ek Referans w3.org/Protocols/rfc2616/rfc2616-sec9.html - Abhijeet
a) GET ile ilgili önemli nokta, güvenilirlik değil, idempotence, b) @Abhijeet: RFC 2616 2014 yılında kaldırılmıştır; RF 7230ff bakın. - Julian Reschke
Bu yanlış. REST doğru yorumlanması için bunu okuyun roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven  veya bu stackoverflow.com/questions/19843480/... - kushalvm
Kushalvm REST'in akademik tanımı pratikte kullanılmamaktadır. - Elliott Beach
REST, web API'ları için yalnızca statik kaynaklar için kullanılmak üzere tasarlanmamıştır. Hangi köprü odaklı. Bununla birlikte, tüm akademik saflarında Fielding, tüm bu HTTP fiillerinin yardımıyla doğrudan bir tarayıcıdan korunacaklarını düşündü, ki bu herhangi bir hızda veya biçimde pratik değil. REST, bir sürü işe yaramaz vızıltılardan başka bir şey değildir ve ASAP'tan vazgeçilmelidir. - Vadim Ferderer


DİNLENME ağın temel mimari ilkesidir. Web'le ilgili şaşırtıcı olan şey, istemcinin (tarayıcıların) ve sunucuların, sunucu ve barındırdığı kaynaklar hakkında önceden herhangi bir şey bilmeden müşterinin karmaşık yollarla etkileşimde bulunabilmesidir. Temel kısıtlama, sunucunun ve istemcinin hem üzerinde hemfikir olması gerektiğidir. medya kullanılan, web durumunda HTML.

Prensiplerine bağlı bir API DİNLENME istemcinin API'nın yapısı hakkında herhangi bir şey bilmesini gerektirmez. Bunun yerine, sunucunun, istemcinin hizmetle etkileşime girmesi gereken bilgileri sağlaması gerekir. bir HTML formu bunun bir örneği: Sunucu, kaynağın yerini ve gerekli alanları belirtir. Tarayıcı bilgiyi nereye göndereceğini önceden bilmiyor ve hangi bilgilerin gönderileceğini önceden bilmiyor. Her iki bilgi formu da tamamen sunucu tarafından sağlanıyor. (Bu prensip denir HATEOAS: Uygulama Devletinin Motoru Olarak Hiper Dosyası.)

Peki, bu nasıl geçerlidir HTTPve pratikte nasıl uygulanabilir? HTTP fiil ve kaynaklara yöneliktir. Ana akım kullanımındaki iki fiil, herkesin tanıyacağı GET ve POST. Bununla birlikte, HTTP standardı PUT ve DELETE gibi birkaçını tanımlar. Bu fiiller daha sonra sunucu tarafından sağlanan 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, mime türünü atadığımız JSON tabanlı özel bir hiper ortam kullanır. uygulama / json + userdb'ye (Ayrıca bir uygulama / xml + userdb'ye ve uygulama / ne olursa olsun + userdb'ye - Birçok ortam türü desteklenebilir). İstemci ve sunucu her ikisi de bu formatı anlayacak şekilde programlanmıştır, ancak birbirleriyle ilgili hiçbir şey bilmiyorlar. Gibi Roy Fielding işaret:

Bir REST API'sı tanımlayıcı çabasının tamamını harcayacaktır.   Kaynakları ve sürüşleri temsil etmek için kullanılan medya türlerini tanımlamak   uygulama durumu veya genişletilmiş ilişki isimlerinin tanımlanması ve / veya   Mevcut standart medya türleri için köprü metni etkinleştirilmiş işaretleme.

Baz kaynağı için bir talep / böyle bir şey döndürebilir:

İstek

GET /
Accept: application/json+userdb

Tepki

200 OK
Content-Type: application/json+userdb

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

Medyamızın açıklamasından, ilgili kaynaklar hakkında "bağlantılar" adlı bölümlerden bilgi bulabileceğimizi biliyoruz. Buna denir Hipermedya kontrolleri. Bu durumda, böyle bir bölümden başka bir istekte bulunarak bir kullanıcı listesi bulabileceğimizi söyleyebiliriz. /user:

İstek

GET /user
Accept: application/json+userdb

Tepki

200 OK
Content-Type: application/json+userdb

{
    "users": [
        {
            "id": 1,
            "name": "Emil",
            "country: "Sweden",
            "links": [
                {
                    "href": "/user/1",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/1",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/1",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        },
        {
            "id": 2,
            "name": "Adam",
            "country: "Scotland",
            "links": [
                {
                    "href": "/user/2",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/2",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/2",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        }
    ],
    "links": [
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

Bu yanıttan çok şey söyleyebiliriz. Örneğin, şimdi POSTing ile yeni bir kullanıcı oluşturabileceğimizi biliyoruz. /user:

İstek

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

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

Tepki

201 Created
Content-Type: application/json+userdb

{
    "user": {
        "id": 3,
        "name": "Karl",
        "country": "Austria",
        "links": [
            {
                "href": "/user/3",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/3",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/3",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

Ayrıca mevcut verileri değiştirebileceğimizi de biliyoruz:

İstek

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

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

Tepki

200 OK
Content-Type: application/json+userdb

{
    "user": {
        "id": 1,
        "name": "Emil",
        "country": "Bhutan",
        "links": [
            {
                "href": "/user/1",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/1",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/1",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

Bu kaynakları manipüle etmek için farklı HTTP fiilleri (GET, PUT, POST, DELETE vb.) Kullandığımıza dikkat edin ve müşteriler kısmında bildiğimiz tek bilgi, medya tanımımızdır.

Daha fazla okuma:

(Bu cevap, noktayı kaçırmak için adil bir eleştirinin konusu olmuştur. Çoğunlukla, bu adil bir eleştiri olmuştur. Aslında tanımladığım şey, REST'in genellikle birkaç yıl önce nasıl uygulandığıyla daha uyumluydu. ilk önce bunu gerçek anlamından ziyade yazdı. Gerçek anlamı daha iyi temsil etmek için cevabı gözden geçirdim.)


2788
2018-03-22 19:37



Hayır. REST, başka bir sesli kelime olarak gösterilmiyordu. SOAP tabanlı veri alışverişine bir alternatif tanımlama aracı olarak ortaya çıktı. REST terimi, verilerin nasıl aktarılacağı ve erişileceği konusundaki tartışmanın çerçevesine yardımcı olur. - tvanfosson
Yine de, REST'in (pratik uygulamada) kalbi "değişiklik yapmak için GET'i kullanmayın, POST / PUT / DELETE kullanmayın", bu da SOAP'ın ortaya çıkmasından çok önce duyduğum (ve takip etmemin) tavsiyesidir. DİNLENME vardır her zaman oradaydı, sadece yakın zamana kadar "bunu yapma yolunun" ötesinde bir isim alamadı. - Dave Sherohman
"Uygulama durumu altyapısı olarak hipermetreyi" unutmayın. - Hank Gay
Bu cevap noktayı özlüyor. Fielding'in tezinde HTTP'den neredeyse hiç bahsedilmiyor. - user359996
Bu cevap REST'in amacından bahsetmiyor ve her şey temiz URI'lar gibi görünüyor. Bu, REST'in popüler algısı olsa da, D.Shawley'in ve yonga cevapları daha doğrudur - mimariye yerleştirilmiş, önbelleğe alma, bunun yerine onunla çalışmak yerine inşa edilmiş özelliklerden yararlanabilme ile ilgilidir. Daha güzel URI'ler çoğunlukla yaygın bir yan etkidir. - T.R.


RESTful programlama hakkında:

  • Kaynaklar kalıcı bir tanımlayıcı tarafından tanımlanır: URI'ler bugünlerde her yerde tanımlayıcı seçimdir
  • Ortak bir fiil kümesi kullanılarak manipüle edilen kaynaklar: HTTP yöntemleri yaygın olarak görülen durumdur - saygıdeğerdir Create, Retrieve, Update, Delete olur POST, GET, PUT, ve DELETE. Ancak REST, HTTP ile sınırlı değildir, şu anda sadece en yaygın kullanılan taşımacılıktır.
  • Bir kaynak için alınan gerçek temsil, tanımlayıcıya değil isteğe bağlıdır: XML, HTTP veya hatta kaynağı temsil eden bir Java Nesnesini isteyip istemediğinizi kontrol etmek için üstbilgileri kabul et
  • nesnedeki durumu korumak ve temsilde devleti temsil etmek
  • Kaynağın temsili içindeki kaynaklar arasındaki ilişkileri temsil eder: nesneler arasındaki bağlantılar doğrudan temsilin içine gömülür
  • Kaynak gösterimleri, temsilin nasıl kullanılacağını ve hangi koşullar altında tutarlı bir şekilde atılması / yeniden kaydedilmesi gerektiğini açıklar: HTTP Cache-Control üstbilgilerinin kullanımı

Sonuncusu muhtemelen REST'in sonuçları ve genel etkinliği açısından en önemli olanıdır. Genel olarak, RESTful tartışmaların çoğu HTTP ve bunun bir tarayıcıdan ve ne kullanılmasından kaynaklandığını gösteriyor. R. Fielding'in mimarlığı ve HTTP'ye yol açan kararları tanımlarken terim olduğunu anladım. Tezi, kaynakların mimarisi ve önbellek yeteneği hakkında HTTP'yle ilgili olduğundan daha fazladır.

RESTful bir mimarinin ne işe yaradığını ve neden işe yaradığını gerçekten merak ediyorsanız onun tezi birkaç kez ve oku Bütün şey sadece Bölüm 5 değil! Sonra içine bakmak neden DNS çalışıyor. DNS'nin hiyerarşik organizasyonu ve yönlendirmelerin nasıl çalıştığı hakkında bilgi edinin. Sonra, önbelleğe alma işleminin nasıl çalıştığını okuyun ve göz önünde bulundurun. Son olarak, HTTP özelliklerini okuyun (RFC2616 ve RFC3040 özellikle) ve önbelleklemenin nasıl ve neden işlediğini düşünün. Sonunda, sadece tıklayacak. Benim için son vahiy, DNS ve HTTP arasındaki benzerliği gördüğüm zamandı. Bundan sonra, SOA ve İleti Geçiş Arayüzlerinin neden ölçeklendirilebileceğini anlamak tıklamaya başlar.

Bir RESTful'un mimari önemini ve performans yansımalarını anlamanın en önemli hilesi olduğunu düşünüyorum. Paylaşılan hiçbir şey mimariler, teknoloji ve uygulama detaylarına asılmaktan kaçınmaktır. Kaynakların sahibi üzerinde durmak, onları yaratmak / sürdürmekle görevli olan kişilere konsantre olmak. Ardından temsilleri, protokolleri ve teknolojileri düşünün.


500
2017-07-04 05:47



Bu soru için bir okuma listesi sağlama cevabı çok uygundur. - ellisbben
Güncelleme için teşekkürler. PUT ve POST güncelleme ile bire bir harita oluşturma ve oluşturma. PUT İstemci, URI'nin ne olacağını dikte ettirmesi durumunda kullanılabilir. POST Sunucu yeni URI'yi ataıyorsa oluşturur. - D.Shawley
PATCH'ı unutma. - epitka
Bir URN, kullanan bir URI'dir. urn: düzeni. Kavramsal olarak hiçbir fark yoktur; Ancak, bir URN, URN tarafından tanımlanan (adlandırılan) kaynağı "bulmak" için ayrı olarak tanımlanmış bir yönteme sahip olmanızı gerektirir. Adlandırılmış kaynaklar ve konumları ile ilişkili olduğunda örtülü birleştirme yapmadığınızdan emin olmak için özen gösterilmelidir. - D.Shawley
@ellisbben Anlaştık. Eğer doğru anlarsam, bu REST'e yol açan tezdir: ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm - Philip Couling


Bu nasıl görünebilir.

Üç özellikli 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ı bilgilerini geri 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 kalacak):

PATCH /user/123
fname=Johnny

Kaydı güncelleştirmek için (ve sonuç olarak) lname ve age NULL olacak):

PUT /user/123
fname=Johnny

392
2017-11-18 20:46



Benim için bu cevap, istenen cevabın özünü yakaladı. Basit ve pragmatik. Verilen diğer birçok kriter var, ancak verilen örnek harika bir fırlatma rampası. - CyberFonic
Son örnekte, @pbreitenbach kullanır PUT fname=Jonny. Bu ayarlanacak lname ve age varsayılan değerlere (muhtemelen NULL veya boş dize ve tamsayı 0), çünkü PUT  tüm kaynağın üzerine yazar Sağlanan temsili verilerle. Bu "güncelleme" ile ima edilen değil, Gerçek bir güncelleme yapmak için PATCH yöntem bu, gösterimde belirtilmeyen alanları değiştirmez. - Nicholas Shanks
Nicholas haklı. Ayrıca, bir kullanıcı oluşturan ilk POST için URI, kullanıcı olarak adlandırılmalıdır. /user/1 hiçbir anlam ifade etmiyor ve bir giriş olmalı /users. Cevap bir olmalı 201 Created ve sadece bu durumda değil. - DanMan
Nicholas ve Danman haklı. Bu cevap kısadır, ancak birkaç kusur vardır. - leslie.zhang
Bu, mutlaka bir RESTful api değil bir API örneğidir. Bir RESTful'a bağlı kaldığı kısıtlamalar vardır. İstemci-Sunucu Mimarisi, Durumsuz, Önbellek-Beceri, Katmanlı Sistem, Tekdüzen Arabirim. - Radmation


REST hakkında harika bir kitap Uygulamada REST.

Okur olmalı Temsili Devlet Transferi (REST) ve REST API'ları hiper metin tabanlı olmalıdır 

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

Richardson Maturity Model

RESTful olmak için bir hizmetin yerine getirilmesi gerekiyor. Uygulama Devletinin Motoru Olarak Hiper Dosyası. (HATEOAS)yani RMM’de 3. seviyeye ulaşması gerekiyor. makaleyi oku detaylar veya qcon konuşmasından slaytlar.

HATEOAS kısıtlaması bir kısaltmadır   Hypermedia için Motor olarak   Uygulama Durumu. Bu prensip   Bir REST arasındaki temel farklılaştırıcı   ve diğer çoğu istemci sunucu formları   sistemi.

...

RESTful bir uygulama istemcisi   erişmek için yalnızca tek bir sabit URL’yi bil   o. Gelecekteki tüm eylemler olmalı   dinamik olarak keşfedilebilir   hipermedia linkler dahil   kaynakların temsilleri   bu URL’den döndürülür.   Standartlaştırılmış medya türleri de   herhangi biri tarafından anlaşılması beklenen   RESTful API kullanabilen istemci.   (Vikipedi, özgür ansiklopedi)

Web Çerçeveleri için REST Litmus Testi web çerçeveleri için benzer bir olgunluk testi.

Saf REST'e yaklaşmak: HATEOAS'ı sevmeyi öğrenmek iyi bir bağlantı koleksiyonudur.

Genel Bulut için SOAP'a karşılık REST Mevcut REST kullanım seviyelerini tartışır.

REST ve versiyonlama Genişletilebilirlik, Versiyonlama, Evrimleşebilirlik vb. konuları tartışır.  Değiştirilebilirlik ile


170
2018-03-22 15:20



Bence bu cevap REST'i anlamak için önemli noktaya değiniyor: ne kelime temsili anlamına gelmek. Seviye 1 - Kaynaklar diyor belirtmek, bildirmek. Seviye 2 - HTTP Fiilleri diyor Aktar (okuma değişiklik). Seviye 3 - HATEOAS, gelecekteki transferleri temsil yoluyla (JSON / XML / HTML döndürdü) sürdüğünüzü söylüyor. Bu, geri dönen bilgilerle bir sonraki konuşma turunu nasıl söyleyeceğinizi bildiğiniz anlamına geliyor. Yani REST, "((temsili durum) aktarımı" yerine "(temsil (durum aktarımı))" ifadesini okur. - lcn
REST ve POX arasındaki fark - nobar


REST nedir?

REST, Temsil Eden Devlet Transferi anlamına gelir. (Bazen   "ReST" yazıyordu.) Bu bir vatansız, istemci-sunucu, önbelleğe   iletişim protokolü - ve neredeyse tüm durumlarda, HTTP   protokol kullanılır.

REST, ağ bağlantılı uygulamaları tasarlamak için bir mimaridir.   Fikir şu ki, CORBA gibi karmaşık mekanizmalar kullanmaktan ziyade,   Makineler arasında bağlanmak için RPC veya SOAP, basit HTTP yapmak için kullanılır   makineler arasında çağrılar.

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   veriyi yayınlamak (oluşturmak ve / veya güncellemek), verileri okumak (ör., sorgu yapmak),   ve verileri silin. Böylece, REST tüm dört CRUD için HTTP kullanır   (Oluştur / Oku / Güncelle / Sil) işlemleri.

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

Basit olmasına rağmen, REST tam özelliklidir; temelde   Web Hizmetleri'nde RESTful ile yapamayacağınız hiçbir şey   mimari. REST bir "standart" değildir. Asla bir W3C olmayacak   örneğin, REST için öneri. Ve REST olsa da   programlama çerçeveleri, REST ile çalışmak çok basit   sık sık gibi standart kitaplık özellikleri ile "kendi rulo" gibi diller   Perl, Java veya C #.

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

http://rest.elkstein.org/


128
2018-03-22 14:53





REST, verileri işlemek için çeşitli HTTP yöntemlerini (esas olarak GET / PUT / DELETE) kullanıyor.

Bir yöntemi silmek için belirli bir URL kullanmak yerine, /user/123/delete), bir DELETE isteği gönderirsiniz /user/[id] Bir kullanıcıyı düzenlemek için URL, bir GET isteği gönderdiğiniz bir kullanıcıya bilgi almak için /user/[id]

Örneğin, aşağıdakilerden bazılarına benzeyen bir dizi URL yerine ..

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 "fiillerini" kullanıyorsunuz ve ..

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

85
2017-07-12 16:33



"HTTP'yi uygun şekilde kullanma" yani "dinlendirici" ile aynı şey değildir (bununla ilgili olsa da) - Julian Reschke
Ayrıca / user / del / 2 ve / user / remove / 2 komutlarını da kullanabilirsiniz ... GET / DELETE / PUT / POST, bu tür şeyleri yapmak için standartlaştırılmış “uygun” bir yoldur (ve Julian'ın dediği gibi, hepsi bu kadar değil. REST var) - dbr
Elbette, ama onları önlemek için bir sebep yok .. REST tekerleği her seferinde yeniden icat etmenizi sağlar. Bir API için, REST büyük (tutarlılık!), Ancak rastgele bir web sitesi yapılandırmak için gerçekten söylemek isterim (değerinden daha fazla güçlük olabilir) - dbr
Vadim, bu sadece RPC olurdu. Bir arama motorunun silme bağlantılarınızı örtebileceğini ve hepsini ziyaret edebileceğinden, verileri değiştirmek için GET kullanmak da tehlikelidir. - aehlke
@aehlke - Bence asıl soru orada "Neden anonim bir kullanıcı sistemden kayıt silme yeteneğine sahip?" - Spencer Ruport


Sisteminizin mimarisinin uygun olduğu programlama REST stili Roy Fielding tarafından ortaya koydu onun tezi. Bu, interneti tanımlayan mimari stil olduğundan (az ya da çok), pek çok insan bununla ilgileniyor.

Bonus cevabı: Hayır. Yazılım mimarlığını bir akademik veya tasarım ağı hizmetleri olarak kullanmıyorsanız, terimi duymak için hiçbir neden yoktur.


64
2018-03-23 17:11



ama düz ileri değil .. olması gerektiği kadar karmaşık hale getirir. - hasen
Ayrıca, REST ve RESTful terimleri, şu anda sadece web uygulamalarının hemen hemen alanında kullanılsa da, teknik olarak, REST'i HTTP'ye bağlayan hiçbir şey yoktur. - Hank Gay
Fielding'in blogunun REST ve yaygın yanlış anlamalarla ilgili makaleleri iyi anlamak, daha kolay olması: roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven - aehlke
@HankGay Daha çok ezoterik olmama sebebi, web servis geliştiricilerinin çoğu REST'i SOAP gibi alternatifler üzerinde harika bir sadeleştirme olarak görmeleriydi. Tüm REST tekniklerinin doğru bir şekilde elde edilmesini zorunlu kılmıyorlar - ve muhtemelen REST fanatiklerini çıldırtıyorlar - ama çoğu zaman sonuçlarının “hiper ortam özellikli” olduğundan emin olmak gibi şeyler için endişelenmelerine gerek yok. - moodboom


RESTful programlama, REST mimari stilini takip eden sistemler (API) oluşturmakla ilgili olurdu.

Dr. M. Elkstein tarafından REST hakkındaki eğitimi anlatan, fantastik, kısa ve kolay bir şekilde anladım.

REST öğrenin: Bir öğretici

REST bir mimari tarzı ağ uygulamaları oluşturmak için.   Fikir şu ki, CORBA gibi karmaşık mekanizmalar kullanmaktan ziyade,   Makineler arasında bağlanmak için RPC veya SOAP, basit HTTP yapmak için kullanılır   makineler arasında çağrılar.

  • Birçok açıdan, HTTP'ye dayanan World Wide Web'in kendisi, REST tabanlı bir mimari olarak görülebilir.

RESTful uygulamalar, veri göndermek için HTTP isteklerini kullanır.   güncelleme), verileri oku (ör. sorguları yapma) ve verileri silme. Böylece, REST   dört CRUD (Create / Read / Update / Delete) işlemi için HTTP kullanır.

Yığın Taşması dışında REST hakkında bir şey duymadığın için aptal hissetmene gerek yok ..., ben de aynı durumdayım !; bu diğer sorulara cevaplar REST şimdi neden büyük oluyor bazı duyguları hafifletebilirdi.


43
2017-07-25 09:05





Soruyu doğrudan yanıtlamıyorsam özür dilerim, ancak tüm bunları daha ayrıntılı örneklerle anlamak daha kolay. Bütün soyutlama ve terminolojiden dolayı Fielding'in anlaşılması kolay değildir.

Burada oldukça iyi bir örnek var:

REST ve Hipermetin Açıklaması: Spam-E Spam Temizleme Robotu

Ve daha da iyisi, burada basit örneklerle birlikte net bir açıklama var (powerpoint daha kapsamlı, ancak html versiyonunda bunlardan yararlanabilirsiniz):

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

Örnekleri okuduktan sonra, Ken'in REST'in hiper metin kullanımına neden neden olduğunu söyleyebildiğini görebiliyordum. Aslında doğru olduğundan emin değilim, çünkü bu / kullanıcı / 123 bir kaynağa işaret eden bir URI'dir ve bu, müşterinin "bant dışı" olduğunu bildiğinden emin olmamanın bana açık olmadığını belirtti.

Bu xfront belgesi, REST ve SOAP arasındaki farkı açıklar ve bu da gerçekten faydalıdır. Fielding dediğinde, "Bu RPC. RPC çığlık atıyor."RPC'nin RESTful olmadığı açıktır, bu yüzden bunun nedenlerini tam olarak görmek faydalıdır. (SOAP bir tür RPC'dir.)


43
2018-03-22 16:36



Harika bağlantılar, teşekkürler. Ben bazı örnek "REST-ful" değil, ancak REST-ful olmak için örnek nasıl değiştirileceğini söylemek reddediyorum bu REST çocuklar bıktım. - coder_tim


REST nedir?

REST, resmi sözlerle, REST mevcut “Web” temellerini kullanarak belli prensipler ü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 stilinde, veri ve işlevsellik kaynaklar olarak kabul edilir ve tipik olarak Web'e bağlanan Tekdüzen Kaynak Tanımlayıcıları (URI'ler) kullanılarak erişilir.
  • İlke 2: Her Kaynak Benzersiz Bir Tanımlayıcı (URI) Tarafından Tanımlanır
  • İlke 3: Basit ve Tekdüzen Arayüzleri Kullanın
  • İlke 4: İletişim Temsili Yapıldı
  • İlke 5: Durumsuz Ol

36
2017-11-22 22:49