JSON parametrelerini kabul eden ve yöntemler için belirli URL'lere sahip bir web hizmetim var, örneğin:
http://IP:PORT/API/getAllData?p={JSON}
Vatansız olmadığı için bu kesinlikle REST değildir. Çerezleri dikkate alır ve kendi oturumu vardır.
RPC mi? RPC ve REST arasındaki fark nedir?
Yanıtlar:
Sadece gönderdiklerinize bakarak REST ile RPC arasında net bir ayrım yapamazsınız.
REST'in bir kısıtlaması, durumsuz olması gerektiğidir. Bir oturumunuz varsa, durumunuz vardır, böylece hizmetinizi RESTful arayamazsınız.
URL'nizde (yani getAllData) bir eylemin olması, RPC'ye yönelik bir göstergedir. REST'te temsilleri değiştirirsiniz ve gerçekleştirdiğiniz işlem HTTP fiilleri tarafından belirlenir. Ayrıca, REST'te, İçerik anlaşması bir ?p={JSON}parametre ile gerçekleştirilmez .
Hizmetinizin RPC olup olmadığını bilmiyorum, ancak RESTful değil. Farkı çevrimiçi olarak öğrenebilirsiniz, işte başlamanıza yardımcı olacak bir makale: RPC ve REST Efsanelerinin Çürütülmesi . Hizmetinizin içinde ne olduğunu daha iyi bilirsiniz, bu nedenle işlevlerini RPC'nin ne olduğu ile karşılaştırın ve kendi sonuçlarınızı çıkarın.
Bir restorana verilen siparişleri modelleyen aşağıdaki HTTP API örneğini düşünün.
Sipariş vermek:
Bir Siparişin Geri Alınması:
Bir Siparişin Güncellenmesi:
Sites.google.com/site/wagingguerillasoftware/rest-series/what-is-restful-rest-vs-rpc'den alınan örnek
Diğerlerinin söylediği gibi, önemli bir fark, REST'in isim merkezli ve RPC'nin fiil merkezli olmasıdır. Sadece şunu gösteren bu net örnekler tablosunu eklemek istedim :
--------------------------- + ---------------------- --------------- + -------------------------- Çalıştırma | RPC (çalışma) | REST (kaynak) --------------------------- + ---------------------- --------------- + -------------------------- Kayıt | POST / kayıt | POST / kişiler --------------------------- + ---------------------- --------------- + -------------------------- İstifa | POST / istifa | SİL / kişi / 1234 --------------------------- + ---------------------- --------------- + -------------------------- Kişi oku | GET / readPerson? Personid = 1234 | GET / kişi / 1234 --------------------------- + ---------------------- --------------- + -------------------------- Kişinin ürün listesini okuyun | GET / readUsersItemsList? Userid = 1234 | GET / kişi / 1234 / öğeler --------------------------- + ---------------------- --------------- + -------------------------- Kişi listesine öğe ekle | POST / addItemToUsersItemsList | POST / kişiler / 1234 / öğeler --------------------------- + ---------------------- --------------- + -------------------------- Öğeyi güncelle | POST / changeItem | PUT / öğeler / 456 --------------------------- + ---------------------- --------------- + -------------------------- Öğeyi sil | POST / removeItem? İtemId = 456 | SİL / öğeler / 456 --------------------------- + ---------------------- --------------- + --------------------------
Notlar
GET /persons/1234) tanımlamak için URL yolu parametrelerini kullanma eğilimindeyken, RPC, işlev girdileri için sorgu parametrelerini kullanma eğilimindedir GET /readPerson?personid=1234).GET /persons?height=tall).POST /signupveya POST /personsyeni kişiyi tanımlayan verileri dahil ettiğinizde).Öyle http kullanarak RPC . Doğru bir REST uygulaması, RPC'den farklı olmalıdır. Yöntem / işlev gibi verileri işlemek için bir mantığa sahip olmak, RPC'dir. getAllData () akıllı bir yöntemdir. REST, istihbarata sahip olamaz, harici bir istihbarat tarafından sorgulanabilen döküm verileri olmalıdır .
Bugünlerde gördüğüm çoğu uygulama RPC'dir, ancak çoğu yanlışlıkla REST olarak adlandırmaktadır. HTTP ile REST kurtarıcıdır ve kötü adam XML ile SABUN. Yani kafa karışıklığınız haklı ve haklısınız, bu REST değil.
Http protokolü bir REST uygulaması yapmaz. Hem REST (GET, POST, PUT, PATCH, DELETE) hem de RPC (GET + POST) HTTP aracılığıyla geliştirilebilir (örneğin: görsel stüdyodaki bir web API projesi aracılığıyla).
İyi, ama o zaman REST nedir? Richardson olgunluk modeli aşağıda verilmiştir (özetlenmiştir). Sadece seviye 3 RESTful'dur.
örneğin: seviye 3 (HATEOAS):
Bağlantı, bu nesnenin bu şekilde güncellenebileceğini ve bu şekilde eklenebileceğini belirtir.
Link, bu nesnenin sadece okunabileceğini belirtir ve biz bunu böyle yaparız.
Açıkçası, veri göndermek REST olmak için yeterli değildir, ancak verilerin nasıl sorgulanacağı da belirtilmelidir. Ama sonra tekrar, neden 4 adım? Neden sadece 4. Adım olup buna REST diyemiyor? Richardson bize oraya gitmemiz için adım adım bir yaklaşım verdi, hepsi bu.
İnsanlar tarafından kullanılabilecek web siteleri oluşturdunuz. Ancak makinelerin kullanabileceği web siteleri de oluşturabilir misiniz? Gelecek burada yatıyor ve RESTful Web Hizmetleri size bunu nasıl yapacağınızı gösteriyor.
Not: REST süper popülerdir, bu yüzden otomatik testtir, ancak gerçek dünya örneklerine gelince ...
REST, kaynaklarla çalışmak için en iyi şekilde tanımlanır, çünkü RPC daha çok eylemlerle ilgilidir.
REST , Temsili Devlet Transferi anlamına gelir. Bağımsız sistemler arasındaki etkileşimleri düzenlemenin basit bir yoludur. RESTful uygulamaları genellikle verileri göndermek (oluşturmak ve / veya güncellemek), verileri okumak (örneğin, sorgular yapmak) ve verileri silmek için HTTP isteklerini kullanır. Bu nedenle REST, dört CRUD (Oluştur / Oku / Güncelle / Sil) işlemlerinin tümü için HTTP kullanabilir.
RPC , temelde kullanıcı isteklerine hizmet etmek için farklı modüller arasında iletişim kurmak için kullanılır. Örneğin, bir sanal makineyi başlatırken nova, bakış ve nötronun nasıl birlikte çalıştığı gibi openstack'te.
Ben şu şekilde tartışırım:
Varlığım verilere sahip mi / sahip mi? Sonra RPC: işte verilerimin bir kopyası, size gönderdiğim veri kopyasını işleyin ve sonucunuzun bir kopyasını bana iade edin.
Aranan varlık veriyi elinde tutuyor / sahipleniyor mu? Sonra DİNLENME: ya (1) bana verilerinizin bir kısmının bir kopyasını gösterin veya (2) verilerinizin bir kısmını değiştirin.
Sonuçta, verinin hangi "tarafının" sahip olduğu / tuttuğu ile ilgilidir. Ve evet, RPC tabanlı bir sistemle konuşmak için REST deyimini kullanabilirsiniz, ancak bunu yaparken yine de RPC etkinliği yapıyor olacaksınız.
Örnek 1: DAO aracılığıyla ilişkisel bir veritabanı deposuyla (veya başka herhangi bir veri deposu türü) iletişim kuran bir nesnem var. Benim nesnem ile API olarak var olabilecek veri erişim nesnesi arasındaki bu etkileşim için REST stilini kullanmak mantıklı. Varlığım verilere sahip değil / tutmuyor, ilişkisel veritabanı (veya ilişkisel olmayan veri deposu) var.
Örnek 2: Çok fazla karmaşık matematik yapmam gerekiyor. Nesneme bir sürü matematik yöntemi yüklemek istemiyorum, sadece her tür matematiği yapabilen başka bir şeye bazı değerler aktarmak ve bir sonuç almak istiyorum. O zaman RPC stili mantıklıdır, çünkü matematik nesnesi / varlığı nesneme bir dizi işlem gösterecektir. Bu yöntemlerin hepsinin ayrı API'ler olarak gösterilebileceğini ve bunlardan herhangi birini GET ile çağırabileceğimi unutmayın. Bunun RESTful olduğunu bile iddia edebilirim çünkü HTTP GET üzerinden arıyorum ama gerçekten kapakların altında RPC. Varlığım verilere sahip / tutuyor, uzak varlık sadece ona gönderdiğim verilerin kopyaları üzerinde manipülasyonlar yapıyor.
Burada bir sürü iyi cevap var. RPC ve REST arasındaki farkları tartışmak için gerçekten iyi bir iş çıkardığından ve buradaki yanıtların hiçbirinde okumadığım bir şeyi yakaladığı için sizi yine de bu google bloguna yönlendiririm.
Bana göze çarpan aynı bağlantıdan bir paragraf alıntı yapardım:
REST'in kendisi, HTTP ve dünya çapında web'in temelini oluşturan tasarım ilkelerinin bir açıklamasıdır. Ancak HTTP, ticari açıdan önemli olan tek REST API olduğu için, çoğunlukla REST'i tartışmaktan kaçınabilir ve sadece HTTP'ye odaklanabiliriz. Bu ikame yararlıdır çünkü insanların REST'in API'ler bağlamında ne anlama geldiğini düşündüklerinde çok fazla kafa karışıklığı ve değişkenlik vardır, ancak HTTP'nin kendisinin ne olduğu konusunda çok daha fazla netlik ve anlaşma vardır. HTTP modeli, RPC modelinin mükemmel tersidir - RPC modelinde, adreslenebilir birimler prosedürlerdir ve sorun etki alanının varlıkları prosedürlerin arkasında gizlidir. HTTP modelinde, adreslenebilir birimler varlıkların kendisidir ve sistemin davranışları, onları yaratmanın, güncellemenin veya silmenin yan etkileri olarak varlıkların arkasına gizlenir.
Bunları farklı kullanım durumlarında şu şekilde anlıyorum ve kullanıyorum:
Örnek: Restoran Yönetimi
REST için kullanım durumu : sipariş yönetimi
- create order (POST), update order (PATCH), cancel order (DELETE), retrieve order (GET)
- endpoint: /order?orderId=123
Kaynak yönetimi için REST temizdir. Önceden tanımlanmış eylemlere sahip bir uç nokta. Bir DB'yi (Sql veya NoSql) veya sınıf örneklerini dünyaya göstermenin bir yolu görülebilir.
Uygulama Örneği:
class order:
on_get(self, req, resp): doThis.
on_patch(self, req, resp): doThat.
Çerçeve Örneği: Falcon for python.
RPC için kullanım durumu : operasyon yönetimi
- prepare ingredients: /operation/clean/kitchen
- cook the order: /operation/cook/123
- serve the order /operation/serve/123
Analitik, operasyonel, yanıt vermeyen, temsili olmayan, eylem tabanlı işler için RPC daha iyi çalışır ve işlevsel düşünmek çok doğaldır.
Uygulama Örneği:
@route('/operation/cook/<orderId>')
def cook(orderId): doThis.
@route('/operation/serve/<orderId>')
def serve(orderId): doThat.
Çerçeve Örneği: Python için Flask