Bu nedenle, RESTful hizmetinin kelime hazinesinde sabit bir fiil kümesi vardır. RESTful bir web hizmeti bunları HTTP yöntemlerinden alır. Sabit bir kelime dağarcığını tanımlamanın bazı avantajları vardır, ama bu noktayı gerçekten anlamıyorum. Belki birisi bunu açıklayabilir.

REST tarafından ana hatlarıyla belirtildiği gibi sabit bir kelime haznesi neden her durum için dinamik bir kelime haznesi tanımlamaktan daha iyidir? Örneğin, nesne yönelimli programlama popüler bir paradigmadır. RPC'nin sabit arayüzleri tanımladığı açıklanmaktadır, ancak insanların neden RPC'nin bu çelişkilerle sınırlı olduğunu varsaydığını bilmiyorum. RESTful hizmetinin içerik yapısını dinamik olarak tanımlaması gibi arayüzü dinamik olarak belirleyebiliriz.

REST'in kelime dağarcığını genişletmeden büyüyebilmesi açısından avantajlı olduğu düşünülmektedir. RESTful hizmetleri daha fazla kaynak ekleyerek dinamik olarak büyür. Nesne başına kelime dağarcığını dinamik olarak belirterek bir hizmeti genişletme konusunda bu kadar yanlış olan ne? Neden sadece nesnelerimizde tanımlanan yöntemleri kelime olarak kullanmıyoruz ve hizmetlerimizin müşteriye bu yöntemlerin ne olduğunu ve yan etkileri olup olmadığını açıklamalarını istemiyoruz?

Esasen, bir sunucu tarafı kaynak yapısının açıklamasının bir kelime dağarcığının tanımına eşdeğer olduğu hissini alıyorum, ancak daha sonra bu kaynaklarla etkileşime girmek için sınırlı kelime dağarcığını kullanmak zorunda kalıyoruz.

Sabit bir kelime hazinesi gerçekten müşterinin endişelerini sunucunun endişelerinden ayırıyor mu? Kesinlikle sunucunun bazı yapılandırma ile ilgili olmak zorunda, bu normalde RESTful hizmetlerinde kaynak konumdur. Dinamik bir kelime dağarcığının kullanılmasından şikayet etmek haksızlık gibi görünüyor çünkü bu yapılandırmayı nasıl bir şekilde anlayacağımızı dinamik olarak aklımızda tutmalıyız. RESTful hizmeti, nesne yapısını hiper ortam aracılığıyla tanımlayarak yapabileceğiniz geçişleri açıklar.

Sabit bir kelime dağarcığını, RPC benzeri bir hizmette kolayca çalışabilecek, kendini tanımlayan herhangi bir dinamik kelime bilgisinden daha iyi yapan şeyin ne olduğunu anlamıyorum. Bu, HTTP protokolünün sınırlı kelime dağarcığı için kötü bir neden midir?

yansıma

Düşüncelerimi yaptığımdan biraz daha iyi açıklığa kavuşturmak için. Herhangi bir genel amaçlı API tasarladığınızı, hatta web'e bakmadığınızı varsayalım. Birisi bu yöntem adlarını yalnızca nesnelerinizde kullanabileceğinizi söylerse mutlu olur musunuz? REST HTTP ile sınırlı değildir, ancak yazdığınız, web'e baktığınız veya başka bir şekilde GET POST PUT ve DELETE yöntemlerini içeren nesnelerden oluştuğu durumu göz önünde bulundurun. Yani tanımlamak istediğiniz object.foo yöntemi mümkün değil. Foo adlı yeni bir nesne tanımlamanız ve onun GET yöntemini çağırmanız gerekir. Aslında REST böyle çalışır ve bu konuda düşünmem biraz rahatsız olur. Foo'nun ne yaptığına dair daha iyi bir genel anlayışınız yok, sadece bir ana nesne üzerinde bir yöntem olan şey için yeni bir nesne oluşturmak zorunda kaldınız. Ayrıca API'nız daha az karmaşık değildir, daha fazla nesne oluşturarak sadece gizli arayüz karmaşıklığına sahipsiniz. RESTful web hizmetleri bizi, ortaya koyduğumuz API bağlamında yeterli olabilecek veya olmayabilecek bir arayüz benimsemeye zorluyor. Belki bunu web'e yönelik API'lerle yapmak için iyi bir neden vardır, ancak her genel amaçlı API'daki her nesne için standart arayüzleri benimsememek için iyi bir neden vardır. Pratik bir örnek takdir edilecektir.

"Fiil" ve "isim" terminolojisi burada biraz talihsizdir. Daha önce de belirttiğiniz gibi, işlev için kolayca nesne oluşturabilirsiniz. Java dışındaki tüm nesne yönelimli dillerin yerleşik dönüşümü vardır ve Java'da bunu her zaman tek bir yöntemle ve genellikle "invoke", "execute", "uygula" veya somesuch olarak adlandırılan çok sayıda nesne ile bitirirsiniz. (yani "fiil" / "isim" ayrımının aslında mantıklı olmadığı programlama dilleri).

REST'in "fiilleri", yöntemlerinizi alıcılara, ayarlayıcılara (siliciler; bir tür ayarlayıcı olarak kabul edilebilir) ve diğerlerine göre sınıflandırmaya benzer. Ve her şeyi alıcılar ve pasiflerle yapmaya çalışıyor. Bunun nedeni:

1. Hem alıcılar hem de ayarlayıcılar idempotent olduğundan, iletişim hatası karşısında daha kolay anlambilim. Kaynağın iki kez elde edilmesinin ek bir etkisi yoktur ve kaynağın zaten sahip olduğu değere ayarlanması da yoktur.
2. Belirli bir arabirimi anlamayan proxy'yi önbelleğe alarak kullanılabilecek bazı anlambilim tanımlama. Harfler önbelleğe alınır ve ayarlayıcıların önbelleği geçersiz kıldığı bilinir.

HTTP başlangıçtan itibaren hem önbellekleri hem de hataya dayanıklılığı göz önünde bulundurarak tasarlanmıştır, bu nedenle bu iki nokta dört temel yönteme yol açar:

• GETbir alıcıdır. Her seferinde sunucu durumunu değiştirmemesi ve aynı değeri, sona erme ve yeniden doğrulama politikası belirleme olasılığıyla döndürmemesi varsayılmaktadır.
• PUTve DELETEayarlayıcı ve silici (= sıfır ile ayarlayıcı). Normalde normal ağ bağlamında kullanılmazlar, ancak REST için anlamlıdırlar.
• POST önbellekleri hiçbir şey üstlenemeyeceği genel bir "çağırmak" mutfak lavabo.

REST, basit yeniden denemeyle hataların kolayca ele alınmasını sağlayan ve önbellek proxy'leriyle güzel çalışan arabirimi uygulamak için ham HTTP veya benzer ağ protokollerinin nasıl kullanılacağını açıklayan bir tasarım modelidir.

Normal nesne yönelimli programlama API'sine kolayca karşılık gelmez. Aslında iyi bir şey olduğunu düşünüyorum. Doğası gereği güvenilmez olan ve gidiş-dönüşlerin süreç içi API'dan farklı tasarım yaklaşımı için orta düzeyde veri çağrısı bile aktarmaktan çok daha yavaş olduğu ağ üzerinden arayüz oluşturmanın zorlukları, bu yüzden farklı göründüğünde insanlar uygulamaya çalışmazlar diğer etki alanından geçersiz deneyim (SOAP, XML-RPC ve benzerlerinin sıkıntısı; prosedür çağrılarına benziyor, ancak böyle çalışmıyor ve çalışmak için acı oluyor).

Temel fikir, karmaşıklığın kaynak temsili yoluyla ifade edilmesidir ve bu nedenle ek fiillere gerek yoktur. Bazılarının söylediği gibi - "REST'te isimler iyi, fiiller kötü."

Dört REST fiiline bakarsanız, temel CRUD işlemleriyle eşleştirilebilir, bu da esas olarak kaynaklarınızla ne istersen yapmanıza izin verir. Yani -

POST - Kaynağı oluştur

GET - Kaynağı okuyun

PUT - Kaynağı güncelle

SİL - Kaynağı sil

Başka neye ihtiyacın var?

Tüm yapıların (işlevler gibi) nesne olduğu bir dil düşünün. Sonra RESTful fiiller sadece kongre ve atama ifadeleri çağırıyor. JavaScript için, bir işlevi çağırmak üzere INVOKE gibi sabit bir fiil sözdizimi, başka bir nesnedeki bir nesneyi silmek için DELETE (js'de silme ile aynı), bir değer atamak için SET ve bir değer döndürmek için RETURN tanımlayabilirsiniz. HTTP fiillerini eşdeğer POST çağırma işlevi, PUT - atama değeri, GET - bir değer döndürme, - DELETE - bir nesneyi silmek için kullanabiliriz. HTTP yöntemlerinin aslında nesne yöntemlerini, gerçek nesne arayüzlerini tanımladığı fikrine kapıldım, aslında açıkça sabit ve sonlu olan temel dil yapıları gibi çok daha düşük seviyeli kavramları tanımlayabildiğini göremedim. aklı başında diller.

Ve elbette yönlendirme / vekil sunucuların üzerinde düşünecekleri sabit bir kelime dağarcığına sahip olmak yararlıdır.

• Çünkü profesyonel bir programcı, aksi takdirde binlerce yöntem ismi olmasa bile yüzlerce kişi bekliyor. Daha küçük bir küçükte anlamsız görünen uygulama büyüdükçe çok büyük bir anlaşma olabilir.

• Çünkü zaten tanımlandıklarında yöntem adları hakkında standartlara gerek yoktur.

• Çünkü kodun ana amacı bu tür ek çeviriler olmadan okunabilir olmaktır.

• Çünkü başka bir sınıfın ne zaman dağılması gerektiğini 'ne zaman' olarak tanımlamaya teşvik eder ve yardımcı olur.

• Kodu devraldığınızda, neyi ve nasıl daha hızlı yaptığını anlamak makul ve aslında mümkündür.

• Ortak bir kelime haznesi ve dolayısıyla soyutlama düzeyi sağlar, böylece diğer ayrıntılara odaklanıp kalıpları görebilirsiniz.

• Ortak kod ve yaklaşımlar kolayca kontrol edilebildiğinden hataları bulmayı kolaylaştırır.

• Web geliştirmede olduğu gibi çoklu 'katmanlarla' çalışırken, hangi URL'lerin hangi eylem adlarıyla eşleştiğini bilmek hata ayıklama için çok kullanışlıdır.

Genel olarak 'her zaman' ihtiyacınız yoktur, ancak çoğu standart gibi, onu kullanmayı denemek çok mantıklıdır!

Alternatif korkunç bir şey: WSDL (diğer adıyla Web Hizmeti Tanımlama Dili), programlı olarak (biraz) keyfi APIS'i tanımlamanın (beceriksiz) bir yoludur.

REST fiilleri ciddi şekilde sınırlar ve neredeyse uygulamaya özel tüm varyasyonları belgenin yüküne iter. Bunu yapmanın yararı, birçok müşteri uygulamasının birçok heterojen hizmetle iletişim kurabilmesidir. İstemciler ve sunucular birbirinden tamamen bilinmiyor olabilir, bazıları henüz yazılmamış olabilir.

Stefan Tilkov'un REST'i güzelce açıkladığı bir podcast var .

Evet, kalan bir api'nin sabit bir fiil kümesi vardır, ancak bununla sınırlı olmamalıdır (veya GET, POST, PUT, DELETE dahil). GET, POST, PUT, DELETE'e, tüm sistemlerin% 80'inde çalışan REST'in varsayılan bir uygulaması olarak bakardım.

Kabuk işlemlerinden daha fazlasını gerçekleştiren diğer sistemler, REST API'leri için kendi fiillerini uygulayabilir (ve uygulayabilir). Yayınlama, Tüketim, Oran, Yorum, Arama, Göz at gibi fiiller bir REST sistemine eklenebilir ve uygulanabilir. Bazıları daha büyük bir kelime dağarcığının daha karmaşık hale getirebileceğini söylese de, cevabım buna bağlı. Hedef kullanıcınız bir POST'un ne olduğunu anlayan teknik başkanlarsa, evet daha karmaşık olabilir; ancak, API'nizin hedef kullanıcıları gerçek kişiler (yani POST'un kodunu bilmeyen ve bilmeyenler), gerçek fiillerin kullanımı çok daha kolaydır. Aslında, API'niz için uygun bir fiil kümesine sahip olmak, URL'lerin kısa kalmasına yardımcı olur (bu, kullanıcıların bunları bir tarayıcıya yazmasını istiyorsanız önemlidir. Özel bir kelime haznesi kullanıyorsanız, d API'nizin ve fiillerinin iyi belgelendiğinden emin olmak istiyorum. Özel bir REST api kullanırken, bir HTTP GET olarak 'salt okunur eylemlerin' ve POST ile 'yazma eylemlerinin' olduğundan emin olmak istersiniz.

Gençlik sosyal ağı, Piczo.com (huzur içinde yatsın), 7 farklı dilde uygulanan genişletilmiş bir REST API (yukarıda belirtilen fiiller dahil) içeriyordu!

Basit iyidir.

Ekstra fiillere ve karmaşıklığa ihtiyaç duyduğunuz durumlar vardır, ancak sorunların çoğu kaynaklar üzerindeki basit CRUD eylemlerine indirgenebilir ve REST teşvik etmeye çalışır. Çoğu web uygulaması hakkında düşündüğünüzde, sonunda aynı basit işlemleri kullanan bir veri deposundaki kayıtları okur ve saklarlar.

object.foo () iyi, ama ne işe yarıyor? Ne geri dönüyor? Nesnenin durumunu veya herhangi bir bağımlılığını değiştiriyor mu? İki kez arayabilir ve aynı sonucu elde edebilir misiniz yoksa size iki farklı değer verecek mi? Object.bar () öğeniz de varsa, bunların belirli bir sırada çağrılması gerekir mi?

Zengin bir API kullanmak için çok fazla bilgi gerekir ve genellikle kendi kurallarına sahiptirler (yani setFoo nesneyi değiştirir, getBar muhtemelen idempotenttir, dispose () veya destroy () aynı nesne üzerinde başka bir çağrı anlamına gelmez mümkün olacak, vb ...)