İnsanlar neden DBAL'ler yerine REST API'sini yapıyorlar?


32

Geçmişte iki şirket, bir web uygulaması aracılığıyla veri sorgulamak için REST API'sinde bulundum. yani. web uygulamasının doğrudan SQL yapmasını sağlamak yerine, bir REST API'sini çağırır ve SQL'i yapar ve sonucu döndürür.

Sorum şu ki ... bu neden bitti?

Üçüncü şahıslara maruz kalacaksa, anlayabilirim. Sınırlı bir REST API'sini tam DB'den daha iyi göstermek. Ancak bu iki şirkette de durum böyle değil.

Bana bu REST API'lerinin DBMS'ler arasında geçiş yapmayı kolaylaştırdığı önerildi. Fakat bu bir veritabanı soyutlama katmanının (DBAL) amacı değil mi? Belki bir ORM'yi DBAL'iniz olarak kullanıyor olabilirsiniz veya belki sadece ham SQL yazabilir ve DBAL'nizin uygunsa DB'ye özgü şeyleri çevirmesini sağlayabilirsiniz (örn., MySQL için LIMIT'i MSSQL için TOP'a çevirir).

Her iki şekilde de bana gereksiz geliyor. Ve bence sorunları teşhis etmeyi de zorlaştırıyor. Eğer web uygulamasındaki bir rapor yanlış numaralar veriyorsa, sadece SQL sorgusunu boşa çıkaramazsınız - REST URL'sini atmanız ve ardından REST API'si olarak hizmet veren projeye girmeniz ve SQL'i ondan çıkarmanız gerekir. Bu yüzden teşhis sürecini yavaşlatan ekstra bir dolaylı katmandır.


3
Sadece temelde CRUD olan uygulamalarla çalıştınız gibi görünüyor - bazı kullanıcılar formlarla veri giriyor ve diğer kullanıcılar verileri aynı formlarla mı yoksa rapor çıktılarıyla mı okuyor? Daha önce karmaşık ve sofistike bir alan modeline ihtiyaç duyan bir sistemle hiç çalışmadıysanız, o zaman bu belirli zihniyeti nasıl elde edebileceğinizi görebiliyorum. Pek çok uygulama, bu ekstra dolaylı katmanı işlem yapmak için gerektirir.
RibaldEddie

1
API'lerle çalıştım (zorunlu olarak REST değil) (diğerlerinin yanı sıra) kendisine iletilen parametreler üzerinde hesaplamalar yaptım. Belki de bu hesaplamalarda bir DBMS kullanılır, ancak muhtemelen mantığın çoğu DB'de yaşamaz. Ancak, çalıştığım firmalardaki dahili API'ler bunu yapmaz. Onlar sadece bir DBMS'yi sorgularlar ve SQL sorgu verbatim'in sonuçlarını tükürürler. Bana öyle geliyor ki, REST API'leri sık sık (her zaman - sık sık değil) modaya uygun olmak için - pratik olmamak üzere yazılmıştır.
neubert,

1
REST API tasarımına, karmaşık bir alanın iyi tasarlanmasını zorlaştıran kesinlikle tuhaflıklar var - yıllar boyunca tanıştığım çoğu geliştirici tasarımı umursamıyor. Kodu olabildiğince hızlı bir şekilde dağıtmak istiyorlar, böylece patronları onları sevecek ve rock yıldızı olduklarını düşünecekler. Bu gerçeği REST gibi bir eğilim ile birleştirdiğinizde, modaya uygun fakat pratik olmayan spagetti API'sini alırsınız. REST'in kendisi ile ilgisi yok.
RibaldEddie

3
bazı web şirketlerinin tüm kullanıcı kayıtlarının bir bilgisayar korsanı tarafından çalındığını nasıl rapor ettiklerini hiç merak ettiniz mi? Hacker'ın nasıl yaptığını hiç merak ettiniz mi? Bir web sunucusunun DB ile doğrudan bir bağlantısı olduğunu düşünüyorsanız, web sunucusu saldırıya uğradığında saldırganın istediği DB'den bir şey seçmek için tam ve sınırsız erişimi olduğunu fark edersiniz. Ortadaki katmanın arkasına yapıştırın ve saldırgan daha sonra yalnızca orta katmandaki yöntemleri çağırabilir. Bunun anlık güvenlik olduğunu söyleyemem, ama çok daha iyi.
gbjbaanb

1
@gbjbaanb: Amacım, web sunucusu verinin dinlenme sunucusu üzerinden erişebilmesidir, böylece web sunucusu saldırıya uğrarsa, saldırgan dinlenme sunucusunu kesmek zorunda kalmadan verilere dinlenme sunucusu üzerinden de erişebilir.
JacquesB

Yanıtlar:


28

Bir istemcinin veri tabanına doğrudan erişmesine izin verirseniz - ki bu, bir veri tabanı soyutlama katmanı ile bile yapacağı gibi:

  • Kodları ile sizin kodunuz arasında bir bağlantı elde edersiniz - özellikle, veritabanı yapınız ve kodları arasında çok güçlü bir bağlantı vardır;
  • Müşteriniz veritabanınızda oldukça istenmeyen şeyler yapabilir - vermemeleri gereken verileri güncelleyip güncellemiyor, çok fazla zaman alan bir sorgu yazıyor, kilitleri temiz bir şekilde almadıkları için bir şeyi kilitleniyor ...
  • Eğer veritabanı yapınızda optimal seçimden biraz daha az seçim yaptıysanız, özellikle müşterilerinizin yeni yapılara geçmesini sağlamak için iyi bir yolunuz yoksa, bu seçimden çıkmak çok zor olabilir.

Yani, REST kısmına hiç dokunmuyorum - veritabanınızı bir API'nin arkasına izole etmek, veritabanını koruyan ekip ve onu kullanan ekiplerin senkronize olmadıklarında, bu bölümlerin yapmasına izin verdiği gibi kendi hızlarında gelişirler.


24

Haklısınız, bir web uygulaması ile bir veritabanı arasında bir REST API katmanı eklemenin hiçbir yararı yoktur ve karmaşıklığı ve performans ek yükü vardır.

Çelişkili cevaplar almanızın nedeni, mimarideki 'müşteri'nin ne olduğu konusunda kafa karışıklığı.

Mimarlığınızda (doğru anlıyorsam), tek bir web uygulamasıyla etkileşimde olan ve sırayla veritabanıyla etkileşime giren tarayıcılara sahipsiniz. Web uygulaması ile veritabanı arasında bir REST API katmanının tanıtılması fayda sağlamaz. Belirtilen tüm faydalar (önbellekleme, veri tabanının yalıtılması vb.) Koddaki veri erişim katmanları ile sağlanabilir.

Ancak bir REST API'sinin mantıklı olduğu başka mimariler var :

  • Veritabanına erişen birden fazla müşteriniz varsa - yani, tek bir web uygulaması değil, aynı veritabanına erişen birden fazla bağımsız web uygulaması. Veri modelinin paylaşılmasını, önbelleklenmesini vb. Sağlamak için ortak bir REST arayüzü oluşturmakta fayda olabilir. Aynı DAL kütüphanelerini paylaşarak, bazı uygulamalar edinebilir, ancak uygulamalar farklı dillerde ve farklı dillerde geliştirilmişse işe yaramaz. platformlar. Bu kurumsal sistemlerde yaygındır.

  • Doğrudan veritabanına erişen birden fazla masaüstü uygulamanız varsa. Bu, web uygulamalarına kıyasla lehine düştü klasik "iki katmanlı" mimarisidir. Bir REST katmanının tanıtılması, veri erişim mantığını merkezileştirmenize izin verir ve özellikle aynı veritabanına doğrudan erişen birden fazla dağıtılmış müşteriye sahip olmasının riskli olduğu için güvenliğin daha sıkı kontrol edilmesini sağlar.

  • Doğrudan sunucudan veri alan JavaScript kodunuz varsa, her durumda REST API gibi bir şeye ihtiyacınız vardır.


1
Cevabını beğendim ama bununla ilgili birkaç sorum daha var. Başka bir soyutlama katmanının ortaya çıkmasıyla performans kaybına ne dersiniz? Ayrıca, tek bir başarısızlık noktası yapmaz (eğer her şey ters giderse) ve olası tıkanıklık (havuzdan DB bağlantısı için bekleyen her uygulama)?
Kasım’da 19:16

@satich: Tam olarak ne sorduğunuzu anlamıyorum, daha belirgin olabilir misiniz? REST katmanı olan veya olmayan tek başarısızlık noktasını mı soruyorsunuz?
JacquesB

Ewan

@Ewan: Evet, ilk mermi noktasında belirttiğim şey bu.
JacquesB

1
@JacquesB Birden fazla web uygulamasının aynı DB'yi paylaştığını, ancak aynı verileri paylaşmadığını, yani her birinin bu DB içindeki ayrı bir veri kümesi üzerinde CRUD işlemleri gerçekleştirdiğini, temel olarak verilerin gerçek anlamda paylaşılmadığını varsayalım. Öyleyse, uygulamaları bir Restful sebat çerçevesinin arkasına koymak herhangi bir anlam ifade eder (ayrıca DB'nin sorgularda iyi bir eşzamanlılık düzeyi sağladığını varsayalım)? Dahası, bu çerçeve, onun üzerinden etkileşimde bulunan pek çok web uygulaması için tek bir başarısızlık noktası kadar darboğaz olmayacak mı?
saat

12

Uyarı: büyük yazı, bazı görüşler, belirsiz 'sizin için en iyi olanı yapın' sonucu.

Genellikle bu, veritabanınızın etrafına "altıgen mimari" uygulamanın bir aracı olarak yapılır. Web uygulamalarına, mobil uygulamalara, masaüstü uygulamalarına, toplu ithalatçılara ve arkaplan işlemlerine sahip olabilirsiniz, hepsi de veritabanınızı aynı şekilde tüketir. Kesinlikle aynı şeyi bir dereceye kadar veritabanınıza erişmek için zengin bir kütüphane yazarak ve tüm işlemlerinizin o kütüphaneyi kullanmasını sağlayarak başarabilirsiniz. Ve gerçekten de, çok basit bir sisteme sahip küçük bir dükkandaysanız, bu aslında gitmesi daha iyi bir yol; Daha basit bir yaklaşım ve daha karmaşık bir sistemin gelişmiş özelliklerine ihtiyacınız yoksa, neden karmaşıklığı ödeyesiniz? Ancak, her biri veritabanınızla ölçeklendirilmesi gereken büyük ve sofistike bir sistem kümesiyle çalışıyorsanız,

Platform bağımsızlığı ve bakımı

Bir veritabanınız varsa ve bu veritabanıyla etkileşimde bulunmak için bir Python kütüphanesi yazarsanız ve herkes veritabanıyla etkileşimde bulunmak için o kütüphaneyi çekerse, bu harika. Ancak diyelim ki bir mobil uygulama yazmanız gerekiyor ve bu mobil uygulamanın şimdi de veritabanıyla konuşması gerekiyor. Ve iOS mühendisleriniz Python kullanmıyor ve Android mühendisleriniz Python kullanmıyor. Belki iOS çalışanları Apple'ın dillerini kullanmak ister ve Android mühendisleri Java'yı kullanmak ister. Sonra veri erişim kitaplığınızı 3 farklı dilde yazarken ve sürdürürken sıkışıp kalacaksınız. Belki iOS ve Android devs, paylaşabilecekleri kodu en üst düzeye çıkarmak için Xamarin gibi bir şey kullanmaya karar veriyor. Mükemmel, muhtemelen veri erişim kitaplığınızı .NET'e aktarmanız gerekecek olması dışında. Ve sonra şirketiniz az önce başka bir şirket satın aldı. ın web uygulaması farklı ancak ilgili bir üründür ve işletme, şirketinizin platformundaki verilerin bir kısmını yeni edinilen bağlı kuruluşun platformuna dahil etmek istemektedir. Sadece bir sorun var: Bağlı kuruluş bir başlangıçtı ve başvurusunun büyük bölümünü Dart'a yazmaya karar verdi. Ayrıca, Xamarin'e pilotluk yapan mobil ekip, hangi sebeplerden dolayı (muhtemelen sizin kontrolünüz dışındaki sebeplerden ötürü) onlar için olmadığına ve geliştirecekleri mobil cihazlara özgü araç ve dilleri kullanmaya karar verdiklerine karar verdi. Ancak bu aşamada iken, ekibiniz zaten .NET'teki veri erişim kitaplığınızın büyük bir bölümünü teslim etmişti ve şirketteki başka bir ekip çılgınca bir Salesforce entegrasyon malzemesi yazıyordu ve hepsini o zamandan beri .NET'te yapmaya karar verdi. için zaten bir veri erişim kütüphanesiydi.

Şimdi, çok gerçekçi bir olay nedeniyle, veri erişim kitaplığınızı Python, .NET, Swift, Java ve Dart ile yazılmış. Onların da olmasını istediğin kadar iyi değiller. Bir ORM'yi istediğiniz kadar etkili kullanamazsınız, çünkü her dilin farklı ORM araçları vardır, bu nedenle istediğinizden daha fazla kod yazmanız gerekirdi. Ve her bir enkarnasyona istediğin kadar zaman ayıramadın, çünkü 5 tanesi var. Kütüphanenin Dart versiyonu özellikle tüylüdür çünkü bazılarının kendi işlemsel işlemlerini yapmanız gerekiyordu çünkü kütüphaneler ve destek gerçekten orada değildi. Bu nedenle, Dart uygulamasının veritabanınız için salt okunur bir işlevselliğe sahip olması gerektiğini ortaya koymaya çalıştınız. ancak işletme, planladıkları her hangi bir şeyin ekstra bir çabaya değmeyeceği konusunda çoktan karar vermişti. Ayrıca, veri erişim kitaplığınızın bu enkarnasyonlarında var olan bazı doğrulama mantığında bir hata olduğu ortaya çıktı. Şimdi bu hatayı tüm bu kitaplıklarda düzeltmek için testler ve kodlar yazmalı, bu kitaplıkların tümünde yaptığınız değişikliklerle ilgili kod incelemeleri almalı, bu kitaplıkların hepsinde KG almalı ve değişikliklerinizi tüm sistemlerde yayınlamanız gerekir. bu kütüphaneler. Bu arada, müşterileriniz memnuniyetsizdir ve Twitter'a girmiştir, asla hayal edemeyeceğiniz zayıflık kombinasyonlarını bir araya getirmek, şirketinizin amiral gemisi ürününü hedef almak yerine tek başına tasarlanmıştır. Ve ürün sahibi durum hakkında çok fazla bir anlayışa sahip olmaya karar verir.

Lütfen bazı ortamlarda, yukarıdaki örneğin kabul edilenden başka bir şey olmadığını anlayın. Ayrıca, bu olaylar dizisinin birkaç yıl boyunca ortaya çıkabileceğini de dikkate alın. Genel olarak, mimarların ve iş adamlarının veritabanınıza başka sistemler kurmaktan bahsetmeye başladıkları noktaya geldiğinizde, o zaman 'veritabanının önüne bir REST API koymak' yol haritanıza almak isteyeceksiniz. Erken bir tarihte, bu veritabanının birkaç sistem tarafından paylaşılmaya başlayacağının açık olduğu durumlarda bir web servisinin / REST API'sinin önüne konulduğunu düşünün. Doğrulama hatasını düzeltmek çok daha hızlı ve kolay olacaktır çünkü 5 kez yerine bir kez yapıyorsunuz. Ve düzeltmeyi bırakmak koordinasyonu daha kolay olurdu, çünkü siz

TLDR; Veri erişim mantığını merkezileştirmek ve çok ince HTTP istemcileri sağlamak, veri erişim mantığını verilere erişmesi gereken her uygulamaya dağıtmaktan daha kolaydır. Aslında, HTTP istemciniz meta verilerden bile oluşturulmuş olabilir. Büyük sistemlerde, REST API daha az kod korumanızı sağlar

Performans ve ölçeklenebilirlik

Bazı insanlar ilk önce bir web servisinden geçmek yerine doğrudan veritabanıyla konuşmanın daha hızlı olduğuna inanabilirler. Tek bir uygulamanız varsa, bu kesinlikle doğru. Fakat daha büyük sistemlerde, bu düşünceye katılmıyorum. Sonunda, bir ölçek düzeyinde, veritabanının önüne bir tür önbellek koymak çok faydalı olacaktır. Belki Hibernate kullanıyorsunuz ve bir Infinispan ızgarasını L2 önbelleği olarak kurmak istiyorsunuz. Web hizmetinizi uygulamalarınızdan ayrı bir şekilde barındırmak için 4 etli sunucu kümeniz varsa, eşzamanlı çoğaltma açık olarak katıştırılmış bir topolojiye sahip olabilirsiniz. Bunu 30 uygulama sunucusundan oluşan bir kümeye koymaya çalışırsanız, bu kurulumda çoğaltmayı açma ek yükü çok fazla olacaktır. ya Infinispan'ı dağıtılmış modda ya da bir çeşit özel topolojide çalıştırmak zorunda kalırsınız ve aniden Hazırda Bekletme'nin önbellekten okumak için ağ üzerinden çıkması gerekir. Artı, Infinispan sadece Java ile çalışır. Başka dilleriniz varsa, başka önbellekleme çözümlerine ihtiyacınız olacaktır. Veritabanına ulaşmadan önce uygulamanızdan web servisinize gitme zorunluluğu olan ağ ek yükü, genellikle kendi ek yüküyle birlikte gelen çok daha karmaşık önbellek çözümlerinin kullanılması gereği ile hızlı bir şekilde telafi edilir.

Ek olarak, REST API'nizin bu HTTP katmanı, başka bir değerli önbellekleme mekanizması sağlar. REST API'niz için sunucularınız önbellekleme başlıklarını yanıtlarına koyabilir ve bu yanıtlar son derece iyi ölçeklenen ağ katmanında önbelleğe alınabilir. Küçük bir kurulumda, bir veya iki sunucuyla en iyi tercihiniz, veritabanında konuştuğunda uygulamada yalnızca bir hafıza içi önbellek kullanmaktır, ancak birçok sunucuda çalışan birçok uygulamanın bulunduğu büyük bir platformda, Önbelleğe almanız için ağ. Çünkü düzgün bir şekilde yapılandırıldığında kalamar veya vernik veya nginx gibi bir şey göreceli olarak küçük donanımlarda çılgınca seviyelere kadar ölçeklenebilir. Her saniyedeki yüz binlerce veya milyonlarca istek, bir HTTP önbelleğinden, bir uygulama sunucusundan veya bir veritabanından daha ucuzdur.

Bunun da ötesinde, bir tona kadar istemcinin hepsinin veritabanınıza işaret etmesi, hepsinin de veritabanına işaret eden birkaç sunucuyu işaret etmesi yerine, veritabanını ve bağlantı havuzlamasını çok daha zor hale getirmesi gerekir. Genel olarak, bir uygulama sunucusundaki asıl iş yükünün çoğu uygulama öğesidir; verilerin veritabanından geri gelmesini beklemek genellikle zaman alır, ancak genellikle çok hesaplı olarak pahalı değildir. Uygulamanızın iş yükünü ele almak için 40 sunucuya ihtiyacınız olabilir, ancak verileri veritabanından almayı düzenlemek için muhtemelen 40 sunucuya ihtiyacınız yoktur. Bu görevi bir web hizmetine ayırırsanız, web hizmeti büyük olasılıkla uygulamanın geri kalanından daha az sayıda sunucuda çalışacaktır, bu da veritabanına daha az bağlantı yapmanız gerektiği anlamına gelir. Bu önemli, çünkü veritabanları genellikle

TLDR; Farklı bir dil ve teknolojiyi kullanan birçok farklı uygulamada gerçekleşen bir şey olduğundan, tek bir adanmış web servisinin içinde olan bir şey olduğunda veri erişiminizi ayarlamak, ölçeklendirmek ve önbelleğe almak daha kolaydır.

Son düşünceler

Lütfen bu düşünceden uzak durmayın "Vay, verilerimi almak için her zaman REST API'lerini kullanmalıyım" veya "Bu salak yanlış yaptığımızı söylemeye çalışıyor, çünkü web uygulamamız doğrudan veritabanına konuşuyor, ama eşyalarımız iyi çalışıyor! " . Yapmaya çalıştığım en önemli nokta, farklı sistemler ve farklı işletmelerin farklı gereksinimleri olduğu; Çoğu durumda, veritabanınızın önüne bir REST API koymak gerçekten bir anlam ifade etmiyor. Bu karmaşıklığı haklı çıkarmayı gerektiren daha karmaşık bir mimaridir. Ancak karmaşıklık garanti edildiğinde, REST API'sine sahip olmanın bir çok yararı vardır. Farklı kaygıları tartabilmek ve sisteminiz için doğru yaklaşımı seçebilmek, iyi bir mühendis yapan şeydir.

Ayrıca, REST API bir şeyleri hata ayıklama yoluna giriyorsa, muhtemelen bu resimde yanlış veya eksik bir şey var. Eklenen soyutlama katmanının kendinden hata ayıklamayı zorlaştırdığına inanmıyorum. Büyük, katmanlı sistemler ile çalışırken, dağıtılmış bir günlük kaydı bağlamına sahip olduğumdan emin olmak isterim. Belki bir kullanıcı bir istek başlattığında, bu istek için bir GUID oluşturun ve bu kullanıcının kullanıcı adını ve yaptığı isteği kaydedin. Ardından, uygulamanız diğer sistemlerle konuşurken bu GUID'i iletin. Doğru günlük toplama ve dizine alma ile tüm platformunuzu sorunu bildiren kullanıcı için sorgulayabilir ve tüm işlemlerinde görünürlük kazanabilir ve olayların nerede yanlış gittiğini hızlı bir şekilde tespit etmek için sistemde dolaşabilirsiniz. Yine, daha karmaşık bir mimari

Kaynaklar: http://alistair.cockburn.us/Hexagonal+architecture https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing


Çok iyi cevap, okumaya değer. Bu harika cevabı yazmaya zaman ayırdığınız için teşekkür ederiz!
Dominic

6

Bir DBAL'nin ne olduğunu doğru anlarsam, cevabı REST arayüzünün müşterileri için herhangi bir dili kullanmanıza izin verdiği ve DBAL müşterileri için tek bir dil kullanmanıza izin veren bir kütüphane olduğu yönündedir .

Bu da, çoğu geliştirme ekibinin olduğu ve hepsinin aynı dilde yetkin olmadığı bir şirket için bir avantaj olabilir. Yazılımlarının doğrudan DB'yi sorgulamasına izin vermek işlevsellikte eşdeğer olacaktır, ancak sizin dediğiniz gibi "tam DB'den daha sınırlı bir REST API'sini göstermek daha iyi".

Daha soyut ifadelerle, siz kendiniz soruyu cevaplıyorsunuz:

Bu yüzden teşhis sürecini yavaşlatan ekstra bir dolaylı katmandır

… ' ' Bilgisayar bilimindeki tüm problemler başka bir dolaylı indirimle çözülebilir '' diyen ünlü bir aforizma olduğu için. :)


6

Sırf aynı şirketin içinde olduğun için her şeyi herkese açık tutman gerektiği anlamına gelmez. REST API'leri, bir şirketteki ekipler arasında sınırlı bir tüketici / tedarikçi ilişkisini net bir sözleşmeyle tanımlamanın bir yoludur. Amazon bu organizasyon biçiminde öncü olmuştur.

API'ler ayrıca belirli bir deyim dizisini kullanmanıza izin veren bir soyutlama katmanı sağlar - mutlaka veritabanınızla aynı terimlerle tüketicilerinizle konuşmak istemezsiniz. Ayrıca her tüketiciyle aynı şekilde konuşmak zorunda değilsiniz.


3

REST'in veritabanı sorguları için olduğunu düşünüyorsunuz, değil. REST şu anda bir şeyin durumunu temsil ediyor. REST kullanmak bir gösterimi değiştirir veya alır, ancak hepsi bu kadar. Eğer bu durum veri tabanı tarafından kullanılabilir hale gelirse, önemi yoktur ve hiç kimse umursamaz çünkü bu temsilin nasıl gerçekleşeceği NASIL REST'in bir parçası değildir ve veri tabanı sorguları da değildir.


Bu veritabanının sorgularını önermiyorum == REST. Tabii ki REST, bir veritabanı soyutlama katmanından çok daha fazlasını yapabiliyor, ancak son zamanlarda çalıştığım iki şirket aslında hepsi bu - bir veritabanı soyutlama katmanı. HTTP isteklerini DB sorgularına çevirmekten başka bir şey yapmaz . Ve tek yaptığın buysa bana öyle geliyor ki, DBAL tarafından daha iyi servis edilirmişsin. Gerçekten de, bana öyle geliyor ki, bugünlerde bazı insanların REST'i kullanmasının tek sebebi modaya uygun olmasıdır - eldeki iş için en iyi çözüm değil.
neubert,

@neubert, DBAL REST'in yaptığı gibi doğrudan internet üzerinden çalışıyor mu?
Rob

Emin. MySQL'e internetteki başka bir bilgisayara ait olan bir IP adresini / etki alanı adını / bağlantı noktasını kullanmasını söyleyebilirsiniz. SSH tünellemesinin yanı sıra (inanıyorum) SSL auth'yu da kullanabilirsiniz. Muhtemelen diğer DBMS'ler de benzer şekilde çalışmaktadır.
neubert,

@neubert: bu durumda, REST API olan bir DBal, değil mi?
RemcoGerlich

2
@RemcoGerlich - elbette, ancak DBAL'iniz olarak REST API kullanmak, gereksiz ve sorunların teşhisini engelleyen bir orta katman ekliyor olabilir. Yani, yeterince geniş bir DBAL tanımı kullanacaksanız, Google SERP’leri DBAL’ler olarak düşünebilirsiniz. Google'ın sunucularından sayfalanmış verileri almak için HTML'yi ayrıştırmanız
yeterlidir
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.