Yazılım geliştirme söz konusu olduğunda, REST gibi sözcükleri duymuş olabilirsiniz. REST, çok yaygın olarak kullanılan bir API mimarisidir ve geliştiriciler, yazılım API'leri tasarlamak için yaygın olarak kullanır. Uygulama programlama arabirimleri, herhangi bir yazılım uygulaması için hayati öneme sahiptir ve REST, API'ler için kullanılan birçok mimariden biridir.
Günümüzde, g RPC mimarisi popülerlik kazanıyor ve ayrıca geleneksel olarak REST API'leri ile ilişkili bazı sorunları çözdüğünü iddia ediyor. Ama nerede farklılar? Ve uygulamanız için hangisini kullanmalısınız? Bu soruların cevabını bilmek için, g RPC ile REST arasındaki farkı ve hangi senaryolarda daha iyi performans gösterdiklerini anlamamız gerekiyor. Ancak tüm bunlara girmeden önce, API'lerin ne olduğuna ve mikro hizmetler için masaya ne getirdiklerine bakalım.
API nedir?
Yazılım uygulamaları, teknik aracılar olarak çalışan API'ler olan uygulama programlama arayüzlerinin kullanımı yoluyla birbirleriyle etkileşime girebilir ve iletişim kurabilir. Bir API, bir kullanıcının isteğini sisteme göndermekten sorumludur ve daha sonra sistemden bir yanıt alır.
İnternetten bir telefon sipariş ettiğinizi hayal edin. Web'e bağlı bir siteye gidersiniz ve sorgunuzla ilgili bilgileri bir sunucuya gönderir. Sunucu daha sonra bilgileri alır, analiz eder ve gerekli adımları attıktan sonra ekranımızda görüntülenen detaylarla bize cevap verir. Bu, API'ler ile mümkün olur.
API, bu tür istemci isteklerinin nasıl gerçekleştirileceğini, hangi veri yapılarının kullanılacağını ve istemcilerin uyması gereken standartları özetler. Ayrıca, bir programın diğerine gönderebileceği sorgu türlerini de açıklar. Hem g RPC hem de REST mimari stilleri, API'leri tasarlamak için yaygın olarak kullanılır.
API'ler ve mikro hizmetler
Uygulamalar, monolitik bir mimariye veya bir mikro hizmet mimarisine sahip olabilir. Yazılımın tüm işlevleri ve modülleri, monolitik bir uygulamada tek bir birim veya kod tabanında bulunur. Bir mikro hizmet uygulaması, aksine, HTTP protokolü gibi arabirimler üzerinden birbiriyle etkileşime giren çok sayıda küçük birimden oluşur.
Monolitik stildeki temel sorun, mühendisler önceden var olan temelin üzerine yeni işlevler ve hizmetler ekledikçe sistemi değiştirmenin, güncellemenin ve genişletmenin zorlaşmasıdır. Uygulamanın bir yönüne yapılacak bir değişiklik, diğer bölümler üzerinde zararlı bir etkiye sahip olabilir. Bir monolitin kodu, ölçeklendirildikten, güncellendikten ve defalarca değiştirildikten sonra yavaş yavaş iç içe geçer ve anlaşılması zor hale gelir ve komple bir sistemin yeniden tasarımı gerekir.
Bu sorun mikro hizmetlerle çözülür. Bu mimari tasarım, bir monoliti, her biri daha sonra ayrı bir uygulama olarak çalıştırılan bileşenlerine ayırır. Bu uygulamaların her birine mikro hizmet denir. Ardından, bu farklı mikro hizmetler API'leri kullanarak bağlanır. API'ler tarafından bağlanan bu mikro hizmet koleksiyonu, daha büyük bir mimari tasarım oluşturmak için bir araya geliyor. API'ler, bir mikro hizmet mimarisine dahil edilen her bileşen arasında bağlantı ve iletişim sağlar. API oluşturmaya yönelik bazı popüler yaklaşımlar GraphQL, RPC ve REST.
RPC nedir?
RPC - Uzaktan Yordam Çağrısı - önceden tanımlanmış bir form kullanarak uzak bir sunucuda bir hizmet yürütmenizi ve aynı formatta bir yanıt almanızı sağlayan bir web mimarisidir. Sorguyu gerçekleştiren sunucunun stili, ister yerel ister uzak sunucu olsun, RPC tasarımı tarafından dikkate alınmaz.
Resim Kaynağı itrelease.com/Yazar Junaid Rehman
Bir RPC API isteğinin temel işlevi, REST API'sininkiyle aynıdır. RPC API istekleri, etkileşim yönergelerini ve etkileşimi mümkün kılan teknikleri belirtir. Daha sonra kullanıcı bu fonksiyonları parametreleri kullanarak çağırır. URL'lerin istek dizesi, işlemleri çağırmak için kullanılan parametreleri içerir.
API istekleri oluşturmak için RPC sistemi bir istemci-sunucu yapısı kullanır. RPC, kullanıcının istediği bilgileri yorumlar ve sunucuya iletir. Sunucular içindeki dahili iletişimler gizlenirken, sunucu kullanıcıya yanıt verir. RPC modeli ayrıca bir kullanıcının belirli bir şekilde bir hizmet istemesini sağlar. RPC, hem merkezi olmayan hem de şirket içi senaryolarda uzaktan yordam çağrılarını destekleme avantajına sahiptir.
REST nedir?
REST - Temsili Durum Aktarımı - kullanıcıların JSON veya XML iletişimi yoluyla arka uç bilgilerine erişebildiği bir istemci-sunucu mimarisini ifade eder. Bir API, aşağıdaki durumlarda RESTful olarak kabul edilir:
- Tutarlı bir arayüze sahiptir ve API istemcilerine belirli uygulama kaynakları sağlar.
- Sunucu ve istemci ayrı ve bağımsız olarak çalışır. Yalnızca uygulamanın bileşenlerine işaret eden URI'ler istemci tarafından bilinecektir.
- Devletsizdir. Bu, yalnızca istemcinin herhangi bir durum bilgisini kaydettiği anlamına gelir. Sunucu, istemci sorgusu hakkında herhangi bir durum verisi kaydetmeyecektir.
- API tarafından sağlanan uygulama varlıkları önbelleğe alınabilir olmalıdır.
- Katmanlı bir mimariye sahiptir.
Hiper ortam ağlarında veri iletimine izin vermek için çeşitli kısıtlamalara dayanan çağdaş mimari tasarımların bir uygulamasıdır. Bir RESTful web API'si, HTTP protokollerini kullanarak hizmetlere bağlanmak için URL kodlu bağımsız değişkenlere ihtiyaç duyar. REST API'leri, durum bilgisi olmayan, genişletilebilir ve güvenilir API'ler oluşturmak için çağdaş web tasarımında kapsamlı bir şekilde benimsenmiştir.
Mikro hizmet sistemini birleştiren her bileşen, REST API herkese açık hale getirildiğinde kullanıcıya veya müşteriye bir varlık olarak gösterilebilir. Bu kaynak HTTP GET, POST, PUT ve DELETE komutları kullanılarak sorgulanabilir.
REST nasıl çalışır?
REST, API isteklerinde belirtilen hizmetlerle çalışırken varsayılan iletişim protokolü olarak HTTP protokolünü kullanır. Kaynak, nesne yönelimli tasarımdaki bir nesneyle karşılaştırılabilir bir şeydir. RESTful kaynağı, bir nesne gibi eylemlere ve niteliklere sahiptir. Genel olarak, REST uygulamaları tipik olarak RESTful eylemleri üzerinde daha az düşünülür ve bunun yerine bir kaynağın niteliklerine daha fazla odaklanır. RESTful çözümler, yalnızca RESTful bir kaynağı temsil etmek için öznitelikleri kullananlardır.
RESTful API'de kullanıcı, JSON, XML veya desteklenen herhangi bir veri biçiminde bir yük içeren bir yanıta neden olan bir URL - Tekdüzen Kaynak Bulucu'ya bir sorgu gönderir. Bu yük, kullanıcının istediği kaynağı temsil eder. Ortak müşteri istekleri şunları içerir:
- Kaynakta nelerin işleneceğini belirten bir HTTP yöntemi
- kaynağın yolu
- Sorgu hakkında veri içeren başlık
- Müşteriye özel mesaj yükü
Başlığın Kabul Et alanında, kullanıcı alabilecekleri veri türlerini belirtir. Yanıt gövdesinde kullanılan ileti teslim biçimini tanımlayan içerik türü bir başlık, sorguyu yapan kullanıcıya sunduğu veri yüküyle birlikte API sunucusu tarafından gönderilir. Yanıt gövdesine, API çağrısının sonuç durumu hakkında kullanıcıyı bilgilendiren bir yanıt kodu da dahildir.
g RPC nedir?
g RPC - Google Uzaktan Yordam Çağrısı - RPC tasarımının bir alt türüdür. g RPC, mikro hizmet mimarisi için esnekliği ve hızı garanti eden yüksek performanslı küresel, açık kaynaklı bir RPC mimarisidir. İşlev çağrıları, çeşitli kodlama dilleri kullanılarak oluşturulan mikro hizmetlerde müşteri etkileşimini sağlamak için g RPC tarafından kullanılır.
Bu teknik, HTTP 2.0 standardını kullanarak RPC API isteklerini uygular, ancak ne sunucu ne de API programcısı HTTP'den haberdar edilmez. Sonuç olarak, RPC ilkelerinin HTTP'ye nasıl çevrildiği konusunda endişelenmek için bir neden olmadığı için karmaşıklık azalır.
Google Uzaktan Yordam Çağrısı, mikro hizmetler arasında veri aktarımını hızlandırmayı amaçlar. Uzaktan geri dönüşe ve aramaya izin vermek için, bir hizmeti tanımlayan, metodolojileri oluşturan ve ilgili değişkenleri belirleyen bir stratejiye dayanır.
Ek olarak, RPC API paradigmasını belirtmek için bir IDL - Arayüz tanımlama dili - kullanır, bu da uzak işlevleri tanımlamayı kolaylaştırır. IDL, hizmet arabirimini ve yük mesajlarının biçimini tanımlamak için varsayılan olarak Protokol Tamponlarını kullanır.
g RPC nasıl çalışır?
HTTP/2 protokolü, akış ve protokol arabellekleri veya protobufs, mesajları iletmek için g RPC API'leri tarafından kullanılır. Protobuf adlı bir serileştirme standardı, kullanıcı kitaplıklarının otomatik olarak oluşturulmasına ve mikro hizmetlerin basit bir şekilde oluşturulmasına olanak tanır. Proto dosyalarında API tasarımcıları, sunucular ve istemciler arasında gönderilen işlemleri ve mesajları tanımlar.
protoc derleyicisi dosyaları yükler ve uzak servislerle iletişim kurmak için kullanıcı ve sunucu yazılımı oluşturur. XML veya JSON biçimleriyle karşılaştırıldığında, protokol arabellekleriyle şifrelenen iletiler önemli ölçüde daha küçüktür, bu da işlemeyi daha az CPU yoğun hale getirir.
Ek olarak, HTTP/2, g RPC API'lerinin kullanılması, RPC tasarımına çeşitli iyileştirmeler getirir. Protokol, paketleri daha küçük, ikili çerçeveli mesajlara bölerek taşınabilir ve küçük hale getiren bir ikili biçim katmanı ekler. Tek bir kanal içinde birçok çağrının yürütülmesi, HTTP/2'nin çift yönlü iletişim mimarisi ile birden çok eşzamanlı sorguyu desteklemesiyle mümkün olmaktadır.
HTTP/2 aktarım protokolü birden çok eşzamanlı akışı destekler, ancak g RPC API'leri bu işlevi kanallar aracılığıyla genişletir. Her kanal, birçok eşzamanlı bağlantı aracılığıyla aynı anda çalışan birkaç akışı barındırabilir. Kanallar, belirli bir adres ve bağlantı noktasında API sunucusuna bağlanmak için basit bir yöntem sunar. Kanallar aracılığıyla bir istemci saplaması da yapılabilir.
g RPC ve REST: karşılaştırma
Google, mevcut API mimarisi stillerinin bazı sınırlamalarıyla başa çıkmak için g RPC bir RPC varyantı olarak oluşturdu. REST API'lerle ilgili bazı sorunları çözer, ancak g RPC API'leri daha yeni bir teknoloji olduğu için bazı sorunlarla karşı karşıyadır. REST API'lerinin uygulamanıza daha uygun olabileceği birçok kullanım durumu vardır. İkisi arasındaki farkları öğrendikten sonra, bu API'lerden hangisinin yazılımınızla daha iyi çalışabileceğine karar verebilirsiniz.
HTTP 1.1 ve HTTP 2 karşılaştırması
REST API'leri tarafından kullanılan istek-yanıt yaklaşımı öncelikle HTTP 1.1'e dayanmaktadır. Bu, bir mikro hizmetin tüm sistemi aşağı çeken birden çok istemciden çok sayıda sorgu alması durumunda modelin her sorguyu ayrı ayrı işlemesi gerektiği anlamına gelir. REST API'leri HTTP 2'de geliştirilebilir, ancak iletişim mimarisi hala istek-yanıt olduğundan, çift yönlü uyumluluk ve akış etkileşimi dahil olmak üzere HTTP 2'nin avantajlarını tam olarak kullanamazlar.
g RPC API'leri bu zorlukla karşılaşmaz. İstemci yanıtı bağlantı modeline bağlıdır ve HTTP 2'ye dayanır. g RPC, çeşitli istemcilerden gelen birçok sorguyu kabul edebilir ve bu istekleri akış bilgisi aracılığıyla aynı anda işleyebilir. Bu koşullar, akış etkileşimi ile çift yönlü iletişime izin verir. Ek olarak, g RPC, HTTP 1.1 tarafından oluşturulanlar gibi tekli etkileşimleri destekler.
g RPC API'leri şunları yönetebilir:
- tekli etkileşimler
Bir müşteri tek bir istekte bulunursa, ancak karşılığında yalnızca bir yanıt verilir. - Sunucu akışı
Bir sunucu, bir istemci sorgusunu bir mesaj akışıyla yanıtladığında, sunucu akışı olarak bilinir. Sunucu ayrıca tüm verileri sağladıktan sonra prosedürü tamamlamak için bir durum mesajı gönderir. - İstemci akışı
Bu, istemci bir dizi mesaj gönderdiğinde ve sunucu tek bir mesajla yanıt verdiğinde meydana gelir. - Çift yönlü akış
Bu, sunucu ve istemci kanalları birbirinden bağımsız olduğu için her iki şekilde de veri aktarımına izin verir.
tarayıcı desteği
Çoğu web API etkileşimi çevrimiçi gerçekleştiğinden, tarayıcı desteği, g RPC ve REST tartışmasında önemli bir husustur. Tarayıcı desteği, büyük olasılıkla REST API'lerinin g RPC göre en önemli avantajlarından biridir. Tüm tarayıcılar tam REST API özelliği ve tarayıcı desteği sunar. Bununla birlikte, tarayıcılarda g RPC işlevselliği hala nispeten sınırlıdır. Ne yazık ki, HTTP 1.1 ve HTTP 2'deki geçişler, bir proxy katmanının yanı sıra gRPC-web'e ihtiyaç duyar. Sonuç olarak, g RPC API'leri, örneğin, belirli kuruluşların arka uç bilgileri ve işlevleri için kullanılan API uygulamalarında, öncelikle dahili veya özel sistemler için kullanılma eğilimi gösterir.
Çoğullanmış akışlar, HTTP/2 protokolü ile kullanılır. Sonuç olarak, çok sayıda müşteri, her biri için yeni bir TCP oturumu açmaya gerek kalmadan paralel olarak sorgu gönderebilir. Ayrıca sunucu, istemcilere ileti göndermek için mevcut bağlantıyı kullanabilir.
Temsili durum aktarım modeli, HTTP 1.1'i entegre ettiği için yaygın tarayıcı desteğine sahiptir. REST etkinleştirdiği HTTP 1.1, her sorgu için bir TCP el sıkışma yöntemi kullanır. El sıkışma zaman aldığından, REST API'leri sıklıkla gecikme sorunları yaşar.
Yük veri yapısı
g RPC ve REST bakarken yük veri yapısına bakıyorsak, g RPC API'leri tasarım gereği Protokol Tamponlarını kullanarak yük verilerini seri hale getirir. Bu yöntem, mesajları küçülttüğü ve oldukça sıkıştırılmış bir yapıya izin verdiği için daha hafiftir. Protokol arabellekleri ikili biçimdedir; bu nedenle, veri alışverişi için bilgileri serileştirir ve seri durumdan çıkarır. Protobuf, yoğun şekilde yazılmış mesajları istemci ve sunucu programlama dillerine otomatik olarak çevirebilir.
Ancak REST, bilgi iletmek ve almak için çoğunlukla JSON veya XML formlarını kullanır. JSON, uyarlanabilirliği ve dinamik verileri kesin bir yapıya bağlı kalmadan iletebilme kapasitesi nedeniyle en yaygın kullanılan formattır, ancak herhangi bir gerektirmez. JSON'un Protobuf'un henüz erişemediği insan tarafından okunabilirlik kalitesi de bir diğer önemli avantajıdır.
Ancak JSON, veri aktarımını içerdiğinde o kadar hızlı veya hafif değildir. Bunun nedeni, REST kullanılırken JSON serileştirilmesi ve hem sunucu hem de istemci tarafında kullanılan programlama dillerine çevrilmesi gerekliliğidir. Bu, veri iletim sürecinde verimliliğe zarar verebilecek ve hata olasılığını artırabilecek ek bir adımdır.
Kod oluşturma
Mühendisler, API sorguları için kod üretimi için Postman gibi üçüncü taraf araçları kullanmalıdır, çünkü g RPC farklı olarak, REST API yerleşik kod oluşturma olanaklarından yoksundur. Bunun aksine g RPC, birçok programlama dilini destekleyen protoc derleyicisi sayesinde yerel kod oluşturma özellikleri sunar. Kod oluşturma, özellikle birden çok platform ve dilde oluşturulmuş çok sayıda hizmeti birleştiren mikro hizmetler için avantajlıdır. Genel olarak, yerleşik kod üretimi, yazılım geliştirme kitinin (SDK) oluşturulmasını kolaylaştırır.
REST API ise yerel kod oluşturma özellikleri sağlamaz. Birkaç dilde API çağrıları için kod üretimi oluşturmak için bir üçüncü taraf programı kullanmanız gerekir. Bir güçlük olmamasına rağmen, g RPC kod üretimi için başka hiçbir hizmete güvenmediğini belirtmek önemlidir.
REST API'leri ne zaman kullanılır?
g RPC ile REST karşılaştırıldığında, mikro hizmetler üzerine kurulu altyapıları entegre etmek için en yaygın kullanılan ve en sevilen API'ler REST API'leridir. REST API'leri, ister dahili bir ağ, ister varlıklarını dünyanın geri kalanına açan açık bir platform oluşturuyor olun, uygulama bağlantısı için çok uzun bir süre varsayılan seçenek olmaya devam edecek gibi görünüyor. REST API'leri, hızlı yineleme ve HTTP protokol standartları gerektiren sistemler için de mükemmeldir.
Üçüncü taraf teknolojileri evrensel olarak desteklediğinden, REST API'leri web hizmetleri geliştirme, mikro hizmetler ve uygulama arayüzleri için ilk tercihiniz olabilir. g RPC farklı olarak geniş tarayıcı desteğine sahiptir ve özel sistemlerle sınırlı değildir. Bu, REST API'lerini birçok bağlamda çok faydalı hale getirebilir.
İnternette çok çeşitli API belgelerine sahip olduğu için REST öğrenmek de daha kolaydır. Bu daha basit öğrenme eğrisi, zaman sıkıntısı çekiyorsanız çok önemlidir. Araştırma ve öğrenme için çok zaman kazanabilir ve hemen uygulamaya başlayabilirsiniz. RESTful API'lerin uygulamalara entegre edilmesi de daha kolaydır. Ayrıca daha iyi ölçeklenebilirlik sunarlar. Uygulamanızı yakında genişletmek istiyorsanız, REST API'lerini kullanmak daha iyi olabilir. Durum ve gizlilik eksikliği, bazı uygulamalarda temsili durum aktarımında sorunlara neden olabilir. Uygulamanızın bir ödeme seçeneği varsa, g RPC daha iyi bir seçenek olabilir.
g RPC API'leri ne zaman kullanılır?
Hem g RPC hem de REST, üçüncü taraf araçların çoğu hala g RPC uyumluluğu için yerleşik işlevsellik sağlamaz. Sonuç olarak, g RPC API'leri çoğunlukla, dış kullanıcılar tarafından erişilemeyen dahili sistemler veya yapılar oluşturmak için kullanılır. Bu nitelik göz önünde bulundurularak, aşağıdaki durumlarda g RPC API'leri kullanılabilir:
- Mikro hizmet bağlantıları
g RPC API'leri, düşük gecikme süresi ve hızlı bant genişliği iletişimi nedeniyle mesaj tesliminin etkinliğinin çok önemli olduğu hafif mikro hizmetlerden oluşan mimarileri bağlamak için özellikle yararlıdır.
- Çoklu dil sistemleri
g RPC, çok çeşitli programlama dilleri için yerel kod oluşturma yeteneği sayesinde, çok dilli bir bağlamda iletişimi yönetmede mükemmeldir.
- Gerçek zamanlı akış
Gerçek zamanlı iletişim gerekliyse, gRPC'nin çift yönlü akışı işleme yeteneği sayesinde, sisteminiz Unary istemci yanıtı etkileşimini beklemek zorunda kalmadan gerçek zamanlı olarak veri iletebilir ve alabilir.
- Düşük güçlü ve düşük bant genişliğine sahip ağlar
Bu tür ağlar, hafif iletişim, gelişmiş verimlilik ve hız sağladıkları için gRPC'nin serileştirilmiş Protobuf oturumları kullanımından yararlanabilir. Örneğin, g RPC API'sinden yararlanacak bir ağ, Nesnelerin İnterneti'dir.
AppMaster nasıl yardımcı olur?
Programlama, geliştiricilerin görevlerini kolaylaştıran yeni teknolojiler ve çerçeveler ile son yıllarda çok değişti. No-code üretim, bunu bir sonraki düzeye taşır. İnsanlar dik öğrenme eğrilerinden geçmek zorunda kalmazlar ve AppMaster gibi kodsuz platformlarla no-code daha hızlı geliştirebilirler.
AppMaster, uygulamanızın özel ihtiyaçlarına göre sıfırdan kaynak kodu oluşturmanıza yardımcı olur. Oluşturulan kod size ait olacak ve ihtiyaçlarınıza göre değiştirebilirsiniz. AppMaster ile uygulamanızın ihtiyaç duyduğu çeşitli modülleri oluşturabilirsiniz. Bu, tüm bir geliştirme ekibinin aynı şeyi yapmasını sağlamaktan çok daha ucuz ve zaman alıcıdır.
Geliştiriciler, no-code kodsuz oluşturma platformunu kullanarak g RPC protokolünü kullanarak arka uç mikro hizmet mimarisi arasında sorgular gönderebilir. Ertesi yıl g RPC desteğini artırmak için hem g RPC web hizmetleri geliştirmeye hem de g RPC mobil uygulamalarına API ekleyeceğiz.
Çözüm
Geçmişte API geliştirme söz konusu olduğunda, temsili durum aktarımı tercih edilen yaklaşımdı. Ancak g RPC ile REST arasında, g RPC API'leri yavaş yavaş daha popüler hale geliyor. Öne çıkan çeşitli özelliklerine rağmen, tarayıcı desteğinin ve API belgelerinin eksikliği gibi bazı sorunlar, onu her yerde kullanmayı zorlaştırıyor. Ancak teknolojik ilerlemeler ve topluluk büyümesiyle birlikte, g RPC günümüzün zorluklarının üstesinden geleceğini umabiliriz.
Son olarak, REST veya g RPC veya hatta GraphQL veya SOAP gibi diğer API metodolojilerinden herhangi biri arasında seçim yapmak projenizin özel ihtiyaçlarına bağlıdır. Bazı uygulamalar g RPC sunduğu avantajlara ihtiyaç duyarken, diğerleri REST sağladığı temel işlevleri gerektirebilir. Bu iki yetenekli teknoloji arasında seçim yapmak için uygulamanızın işlevlerini değerlendirmeniz ve vakaları kullanmanız gerekir.
