+- Delphi Can (https://www.delphican.com)
+-- Forum: Delphi (https://www.delphican.com/forumdisplay.php?fid=3)
+--- Forum: Genel Programlama (https://www.delphican.com/forumdisplay.php?fid=6)
+--- Konu Başlığı: Delphi Rest Api (/showthread.php?tid=1570)
Cvp: Delphi Rest Api - Fesih ARSLAN - 27-11-2017
(27-11-2017, Saat: 17:40)ismailkocacan Adlı Kullanıcıdan Alıntı:(27-11-2017, Saat: 17:25)Abdullah ILGAZ Adlı Kullanıcıdan Alıntı: E-fatura gibi milyonlarca datanın aktığı sistemlerin altyapısının planlamasında xml tercih ediliyorsa bir sebebi vardır kesinlikle.Tercih sebebi; XML veriyi, şematron yardımıyla dinamik olarak kontrol edebiliyor olmak olabilir.REST'de henüz şematrona benzer bir yapı var mı bilmiyorum.
Henüz yok.
İlk zamanlar XML Mapper (Şimdiki adı ile XML Binding)'da yoktu. İhtiyaç ve taleplere binaen, böyle bir entegrasyon yapıldı.
Yakın zamanda REST mimarilerinde sıklıkla kullanılan JSON için de böyle bir eklenti kaçınılmaz olacaktır.
(Dört Gözle) bekliyoruz.
Cvp: Delphi Rest Api - Abdullah ILGAZ - 27-11-2017
(27-11-2017, Saat: 17:40)ismailkocacan Adlı Kullanıcıdan Alıntı:(27-11-2017, Saat: 17:25)Abdullah ILGAZ Adlı Kullanıcıdan Alıntı: E-fatura gibi milyonlarca datanın aktığı sistemlerin altyapısının planlamasında xml tercih ediliyorsa bir sebebi vardır kesinlikle.Tercih sebebi; XML veriyi, şematron yardımıyla dinamik olarak kontrol edebiliyor olmak olabilir.REST'de henüz şematrona benzer bir yapı var mı bilmiyorum.
XML'i tercih etmelerinde bir çok sebep olabilir. Söylediğiniz gibi schematron validation en önemli unsurlardan sadece bir tanesi. Open data interchange meselesi de bir diğer boyutu. CSV, PDF ve XML bilgisayar teknolojisinin gelişimi ile birlikte yüz tutmuş ve faal olarak kullanılmaya devam edilen en yaygın veri tipleridir. XML'in record mantığı ile ilerlemesi ve attribute endeksli olması da bir diğer avantajı.
Kısa bir snippet vermek gerekirse; UBL'in mantığında her şey attribute üzerine kurulu. Bir faturaya vergi girmelisiniz. Faturada bulunan her satırın bir vergilendirme usulü olur. Bu, dünya üzerinde bir çok şekilde sağlanabiliyor. Ürünün tipi, hammaddesi, özelleştirilmesi vs. Mesela Türkiye için yeni çıkan kanunla birlikte gazozlara ötv uygulaması başlayacak. Yani gazoz satışı yapılan bir faturada artık sattığınız X marka gazoz'un xml node'unda bir attribute olarak vergi kodu ötv olan 111 (örn.) değerini set etmeniz gerekecek. Ek olarak ikinci bir vergi kodunu ekleyip (record) bu sefer de kdv vergisini tanımlayıp attribute kısmına 0015 (kdv'nin ubl kod karşılığı) eklemeniz gerekecektir.
Ve yasa gereği bu verilerin saklama zorunluluğu olmasından dolayı tüm verileri xml'in envelope nesnesi ile işaretleyip, tıpkı kağıt fatura/belgelerin arşivlenme usulüne uygun hale getirerek birer envelope id oluşturup, bununla birlikte sisteme almak her şeyi kontrolünüz dahilinde yönetmenizi sağlar.
Delphi Rest Api - SimaWB - 27-11-2017
(27-11-2017, Saat: 17:25)Abdullah ILGAZ Adlı Kullanıcıdan Alıntı: E-fatura gibi milyonlarca datanın aktığı sistemlerin altyapısının planlamasında xml tercih ediliyorsa bir sebebi vardır kesinlikle.
Bu mantıkla; Windows daha çok kullanıldığına göre vardır bir bildikleri. Yada Dünya'da Hristiyanlar daha fazla olduklarına göre vardır bir bildikleri
Dipçe: Tam işten çıkarken yukarıdakileri okudum. Ortalığı bulandırıp kaçayım dedim
Cvp: Delphi Rest Api - Abdullah ILGAZ - 27-11-2017
(27-11-2017, Saat: 18:33)SimaWB Adlı Kullanıcıdan Alıntı:(27-11-2017, Saat: 17:25)Abdullah ILGAZ Adlı Kullanıcıdan Alıntı: E-fatura gibi milyonlarca datanın aktığı sistemlerin altyapısının planlamasında xml tercih ediliyorsa bir sebebi vardır kesinlikle.
Bu mantıkla; Windows daha çok kullanıldığına göre vardır bir bildikleri. Yada Dünya'da Hristiyanlar daha fazla olduklarına göre vardır bir bildikleri
Dipçe: Tam işten çıkarken yukarıdakileri okudum. Ortalığı bulandırıp kaçayım dedim
Genel geçerlilikler ve kabul görmüş standartlar çoğunluğun aklına yatıyorsa bu daha uygun olanıdır. Anti-tez üretmek adına; Her ülkede trafik lambalarının niçin renk renk olmadığını, yeşil ışıkta dur emri verilen ülkelerin olmadığını, gündüzleri insanların uyumayı seçip geceleri işe gitmemeleri (mesai kavramı açısından söylüyorum), gibi çoğaltılabilecek bir çok şey vardır.
Genelde konu tercihlere geldiği zaman tek bir doğru hiçbir zaman olmuyor. Renkler, zevkler, istekler herkese göre şekillenebilecek türden şeylerdir. Windows'un çok kullanılıyor olmasından ötürü tüm eğlence sektörü (video oyunu ve eğlence aplikasyonları) öncelikli olarak (Oyun konsollarını ayrı tutalım) Windows tabanına geliştirme yapıyor. Ekran kartı üreticileri, Microsoft ve Oyun geliştiricileri arasındaki pazar payından bahsediyorum. O halde oyun oynamak isteyen birisi Linux tabanında oynayamıyorsa vardır bir bildiği mi diyeceğiz
.Net servisinde daha önce sadece Json parser ile metod sonuçlarını objeye dönüştürüp string çıktı içerisinde json veri sundum. Bunun dışında hiçbir şekilde kullanmadım. Avantajları olacağı gibi dezavantajlarının olacağı da aşikar gözüküyor. Bazı gerçeklikler ne yazık ki birden fazla olaya ve sürece bağlı ilerliyor. O yüzden tercih şansımızın olmadığı yada alternatifini üretme imkanımızın olmadığı her şeyde bize sunulanı kullanmak durumundayız sayın hocam
Bu bakışla ilerlersek; Windows'u sırf Microsoft politikalarından ötürü eleştirmekten başka bir şey yapmıyorken, kullanmakta olduğumuz Delphi IDE'nin yine bir tek Windows tabanında çalışıyor olması manidar değil midir
Delphi Rest Api - Bahadir.Alkac - 28-11-2017
(27-11-2017, Saat: 17:25)Abdullah ILGAZ Adlı Kullanıcıdan Alıntı:(27-11-2017, Saat: 17:03)Bahadir.Alkac Adlı Kullanıcıdan Alıntı: Merhaba,
İşin doğrusu ben de SOAP taraftarıyım. Ama SOAP'ın çok ciddi bir XML yükü var. Bu yüzden de özellikle yüklü miktarlarda veri göndermek istediğinizde çok fazla gereksiz XML verisi de göndermiş oluyorsunuz. REST API'si hem mimarisi, hem de genelde JSON kullandığı için bu sorun çok daha az.
Abdullah Bey, acaba siz kendi projelerinizde SOAP'ın bu ciddi XML veri yükünü yönetmek için bir şeyler yapıyor musunuz? Yapıyorsanız neler yapıyorsunuz?
Teşekkürler
Bahadır Bey, öncelikle taraf güçlendirmesi yaptığınız için teşekkür ederim.
Projelerin genişleme türüne göre tedbir alıyoruz. Bir projenin sadece windows tabanlı (ki bu durumda da yapıyoruz) olmasında yaklaşım biraz değişiyor. Mobil, web ve masaüstü platformları ne kadar bir arada ve çeşitli işlemleri paylaşıyor olsa da, hepsinin uygulama katmanını web servis üzerinde yapıyoruz. Böylece her platforma has baştan kodlamalar yapılmıyor. Platform bazlı çeşitli kontrol ve denetimler dışında kapsülleme için oluşturulan veri tipleri dahi bu servisler üzerinde tasarlanıyor.
İlerleyen zamanda projeye 3. parti geliştirme yapmak isteyenler olduğunda altyapının müsait olmasından ötürü talep edilen metodların ayrılıp bir token ile verildiği ek servislere taşımak çok kısa oluyor. Orada da çok katmanlı mimari üzerinden servis geliştirdiğimiz için n tane asmx dosyasına business metodlarını çıkartmamızın bir sakıncası olmuyor.
Dokümantasyon işi çok fazla yük alıyor. Onun haricinde XML parse işlemleri ile uğraşmıyoruz. Doğrudan wsdl'den oluşan pas dosyaları ile yerel soap nesnesi oluşturup metodları invoke ediyoruz. Tek tip mantığını da veritabanına göre planladığımız zaman her platform için başka kişiler geliştirme yapacağını hesaba koyarsak; tek bir dil ve standart üzerine yoğunlaşılıyor. Metod imzaları, isimlendirmeler, complex types dediğimiz veri yönetimi için oluşturulan özel obje tiplerine kadar her şey ortak kalmış oluyor.
Her ne kadar xml yük gibi gözükse de, güvenliği ve kararlılığı açısından benim vazgeçmem ilk aşamada çok zor gözüküyor.
E-fatura gibi milyonlarca datanın aktığı sistemlerin altyapısının planlamasında xml tercih ediliyorsa bir sebebi vardır kesinlikle. Buradan yola çıkarak; UBL (evrensel iş dili) standartları gibi kendi jargonunuza has standart bir isimlendirme politikası çok ciddi anlamda kolaylık sağlar.
Siz nasıl yaklaşıyorsunuz peki? Yönetimi, kullanımı ve dağıtımı açısından neler planlıyorsunuz?
Merhaba,
Ben çok katmanlı mimari kurmak zorunda olduğum projelerde ORM nesnelerini binary veri olarak gönderiyorum. Aşağıda standart yapılarla benim kullandığım yapıya örnek veriyorum:
type TOgrenci = class(TRemotable) published // Öğrenci ile ilgili bilgiler burada end; function OgrenciEkle(AOgrenci: TOgrenci): TOgrenci;
Yukarıda iki tane ciddi sorun var:
1. TOgrenci, TRemotable sınıfından türemek zorunda ve serialize etmek istediğiniz bütün özellikler published kısmında yazılmalı.
2. XML içinde hem fonksiyon tanımı, hem de TOgrenci tanımı olmak zorunda.
Sadece öğrenci ekleyeceğiniz zaman çok ciddi sorun değil, ama bir de 10.000 kişilik öğrenci listesini almak istediniz diyelim. Tamam, 10.000 biraz kışkırtıcı bir sayı ama olsun
Aşağıda da benim kullandığım yapı var:
type TOgrenci = class(TMyBaseObject) public // Öğrenci ile ilgili bilgiler burada procedure SaveToStream(AStream: TStream); procedure LoadFromStream(AStream: TStream); procedure SaveToDataSet(....); procedure LoadFromDataSet(...); class procedure DataSetToObjectList(...); class procedure DataSetToStream(...); end; function OgrenciEkle(AOgrenci: TByteDynArray): TByteDynArray;
Dikkat edecek olursanız TOgrenci ciddi bir biçimde değişti. Burada açıklamam gereken bir şey var: TOgrenci aslında ucuz ve eksik bir ORM sınıfı. Daha çok kendi ihtiyaçlarıma göre tasarlanmış. Ben ORM kütüphanelerinde sorgu üretme kısmının gereksiz buluyorum. Bunun yerine stored procedure (SP) yazmak veya ORM sınıflarını extend edip gerekli fonksiyonu yeni sınıfın içine yazmak daha doğru geliyor. TOgrenci de aslında böyle. Kendi özelliklerini ve bazı fonksiyonlarını veri tabanına göre otomatik üretiyorum.
Avantajları şunlar:
- SOAP XML dosyası küçük oluyor, çünkü ortadaki tek tanım TByteDynArray gibi byte array.
- SOAP XML serialize etme işlemi çok güzel görünebilir, ama ciddi bir hız maliyeti var. Bu maliyeti ortadan kalkıyor. Onun yerine her sınıf kendisini herhangi bir stream'e yazmayı ve stream'den okumayı biliyor. Bu da çok hızlı veri transferi anlamına geliyor.
- Bu yapı sayesinde çok katmanlı mimarinin bütün avantajlarını kullanabiliyorum. Nesneler kendilerini DataSet'lere yazmayı bildiği için Client tarafında kullandığım bir MemTable sayesinde Delphi'nin TDataSource nesnesini kullanabiliyorum. Bu da istemci tarafında işleri inanılmaz derecede kolaylaştırıyor ve hızlandırıyor.
Herşey bu kadar güzel değil
Bu sistemin de bir takım sorunları var:- Client ve Server daima aynı sürümde olmalı. Daha doğrusu veri tabanı nesneleri aynı sürüm olmalı. Bu da güncellemeleri biraz zorlaştırıyor.
- Fonksiyonların ve parametrelerin isimlendirmesine çok dikkat etmek gerekiyor. Aksi takdirde REST sistemlerinde karşılaştığımız sorun çıkıyor: Fonksiyonun ne iş yaptığını anlamak için doküman okumak gerekiyor. Ben bunu şöyle idare ediyorum: Çok özel durumlar hariç fonksiyon hep veri tabanındaki ismine uygun oluyor. Örneğin sadece öğrenci tablosundan bir kayıt alacaksam fonksiyonun adı OgrenciGetir oluyor, ama öğrencinin bazı detaylarını da JOIN ile alıp getirmem gerekiyorsa o SP'nin adını kullanıyorum. Yani SpOgrenciGetir oluyor. Tabii veri tabanında da SpOgrenci diye bir SP var. Kısaca fonksiyon/parametre adında kullanılması gereken sınıfla ilgili bir ipucu oluyor.
Alıntı:Bu mantıkla; Windows daha çok kullanıldığına göre vardır bir bildikleri. Yada Dünya'da Hristiyanlar daha fazla olduklarına göre vardır bir bildikleri
İşin komiğibu mantık kısmen de olsa doğru
Windows'un bu kadar çok kullanılmasının sebebi Windows işletim sistemine her dilde çok kolay program yazılabilmesi. Ünlü "developers, developers, developers" lafını bilirsiniz. Programcılar kolay program yazıyorsa, kullanıcılar da mecburen o programları kullanacaklar. Günümüzde Apple kendi işletim sistemlerinde bunu bir nebze aştı ve mobil piyasayı anında değiştirdi. Peşinden Google yaptı aynısını. Her ikisinin de ortak noktası aynı: Yaratıcı, yeni ve kolay program yazılabilir olması. Burada şu ufak detayı gözden kaçırmayın: Windows'da, standart kullanıcıların rahatlıkla kullanabileceği (yani görsel) programlar yazmak çok kolay!Bahadır Alkaç
Delphi Rest Api - vkamadan - 28-11-2017
Merhabalar ,
Eğer client uygulamayı da kendim yazıyorsam bende gidip gelen XML paketlerini önemli ölçüde küçültmek adına hem istemci hem sunucu uygulamanın XML giriş çıkış notlarında sıkıştırma/açma yöntemi kullanıyorum ,
soap server uygulaması tarafında TWebModule ün üzerin deki THTTPSoapDispacher in Dispatcher.BeforeDispatchEvent olayında client tarafından sıkıştırılmış olarak gelmesini beklediğim REQUEST i açıyor ,
Dispatcher.AfterDispatchEvent ında cliente dönülecek RESPONSE ü sıkıştırıyor , istemci uygulama tarafında da THTTPRIO nesnesi üzerinde ki OnBeforeExecute olayında server a gidecek REQUEST i sıkıştırıyor , OnAfterExecute olayında da serverdan dönen cevabı açıyorum.
İyi çalışmalar.
Delphi Rest Api - yhackup - 28-11-2017
(28-11-2017, Saat: 08:35)vkamadan Adlı Kullanıcıdan Alıntı: Merhabalar ,
Eğer client uygulamayı da kendim yazıyorsam bende gidip gelen XML paketlerini önemli ölçüde küçültmek adına hem istemci hem sunucu uygulamanın XML giriş çıkış notlarında sıkıştırma/açma yöntemi kullanıyorum ,
soap server uygulaması tarafında TWebModule ün üzerin deki THTTPSoapDispacher in Dispatcher.BeforeDispatchEvent olayında client tarafından sıkıştırılmış olarak gelmesini beklediğim REQUEST i açıyor ,
Dispatcher.AfterDispatchEvent ında cliente dönülecek RESPONSE ü sıkıştırıyor , istemci uygulama tarafında da THTTPRIO nesnesi üzerinde ki OnBeforeExecute olayında server a gidecek REQUEST i sıkıştırıyor , OnAfterExecute olayında da serverdan dönen cevabı açıyorum.
İyi çalışmalar.
Peki sıkıştırma açma zaman almıyor mu , bunun yerine veriyi JSON olarak gönderip almak daha mantıklı olmaz mı ?
Hatta JSON olarak gönderip alırken sıkıştırırsak havada çok minik paketler uçacaktır
Delphi Rest Api - Bahadir.Alkac - 28-11-2017
(28-11-2017, Saat: 08:35)vkamadan Adlı Kullanıcıdan Alıntı: Merhabalar ,
Eğer client uygulamayı da kendim yazıyorsam bende gidip gelen XML paketlerini önemli ölçüde küçültmek adına hem istemci hem sunucu uygulamanın XML giriş çıkış notlarında sıkıştırma/açma yöntemi kullanıyorum ,
soap server uygulaması tarafında TWebModule ün üzerin deki THTTPSoapDispacher in Dispatcher.BeforeDispatchEvent olayında client tarafından sıkıştırılmış olarak gelmesini beklediğim REQUEST i açıyor ,
Dispatcher.AfterDispatchEvent ında cliente dönülecek RESPONSE ü sıkıştırıyor , istemci uygulama tarafında da THTTPRIO nesnesi üzerinde ki OnBeforeExecute olayında server a gidecek REQUEST i sıkıştırıyor , OnAfterExecute olayında da serverdan dönen cevabı açıyorum.
İyi çalışmalar.
Sıkıştırma işini nesneleri yazdığım stream'i sıkıştırarak yapıyorum. Burada tercih edilen algoritma yüksek hızlı/düşük oranlı sıkıştırma. Zaten sıkıştırılan veriler de çok küçük. Bu yüzden ciddi bir yük getirmiyor. Daha doğrusu getirisi maliyetinden daha fazla olduğu için tercih ediyorum.
(28-11-2017, Saat: 08:50)yhackup Adlı Kullanıcıdan Alıntı:(28-11-2017, Saat: 08:35)vkamadan Adlı Kullanıcıdan Alıntı: Merhabalar ,
Eğer client uygulamayı da kendim yazıyorsam bende gidip gelen XML paketlerini önemli ölçüde küçültmek adına hem istemci hem sunucu uygulamanın XML giriş çıkış notlarında sıkıştırma/açma yöntemi kullanıyorum ,
soap server uygulaması tarafında TWebModule ün üzerin deki THTTPSoapDispacher in Dispatcher.BeforeDispatchEvent olayında client tarafından sıkıştırılmış olarak gelmesini beklediğim REQUEST i açıyor ,
Dispatcher.AfterDispatchEvent ında cliente dönülecek RESPONSE ü sıkıştırıyor , istemci uygulama tarafında da THTTPRIO nesnesi üzerinde ki OnBeforeExecute olayında server a gidecek REQUEST i sıkıştırıyor , OnAfterExecute olayında da serverdan dönen cevabı açıyorum.
İyi çalışmalar.
Peki sıkıştırma açma zaman almıyor mu , bunun yerine veriyi JSON olarak gönderip almak daha mantıklı olmaz mı ?
Hatta JSON olarak gönderip alırken sıkıştırırsak havada çok minik paketler uçacaktır
Ufak bir detayı gözden kaçırmışsınız: Biz XML'i çok sevdiğimizden değil (ki seviyorum) SOAP emrettiği için kullanıyoruz. Yani üstümüze binen yük tercihlerden kaynaklanmıyor. Bu yüzden dediğinize katılıyorum, ama burada geçerli bir sav değil.
Son olarak ufak bir detay daha var: Verileri byte array olarak gönderdiğimiz zaman string<->native data type değişimi yapmıyoruz. Okuduğunuz veri ister XML, ister JSON olsun, string çevirimi işlemleri bolca var. Oysa stream içinden veri okuduğunuzda ortada çevirim olmadığı için okuma/yazma (serialize/deserialize) işlemleri SOAP/REST'e göre çok ama çok daha hızlı oluyor.
İyi çalışmalar
Cvp: Delphi Rest Api - yhackup - 29-11-2017
Bu yöntemle, Çok basit, minicik bir veri'de %10 tasarruf yaptım. Büyük ölçekli verilerde daha fazla tasarruf anlamına gelecektir.
function TWebModule2.GetMethodName(TX: TStringList): String;
const ass = '>'+
' </SOAP-ENV:Body>'+
'</SOAP-ENV:Envelope>';
begin
Result := Copy(TX.Text,Pos('</NS1:',TX.Text)+6,50);
Result := Trim(Copy(Result,0,Pos('>',Result)-1));
end;
procedure TWebModule2.HTTPSoapPascalInvoker1AfterDispatchEvent(const MethodName: string; SOAPResponse: TStream);
const Envelope = '<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">'+
'<SOAP-ENV:Body SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:NS1="urn:KubarIntf-IKubar">'+
'<NS1:%s>'+
'<return xsi:type="xsd:string">';
const Envelope2 = '</return>'+
'</NS1:%s>'+
'</SOAP-ENV:Body>'+
'</SOAP-ENV:Envelope>';
var
Tx:Tstringlist;
MethodNamex:string;
begin
SOAPResponse.Position := 0;
Tx := Tstringlist.Create;
try
Tx.LoadFromStream(SOAPResponse);
MethodNamex := GetMethodName(Tx);
if (Pos(MethodNamex,Tx.Text) <> 0) then
begin
Tx.Text := StringReplace(Tx.Text, Format( Envelope ,[MethodNamex] ),'',[rfReplaceAll]);
Tx.Text := StringReplace(Tx.Text, Format( Envelope2 ,[MethodNamex] ),'',[rfReplaceAll]);
Tx.Text := Trim(StringReplace(Tx.Text,'<?xml version="1.0"?>','',[rfReplaceAll]));
SOAPResponse.Size := 0;
SOAPResponse.Position := 0;
Tx.SaveToStream(SOAPResponse);
end;
finally
Tx.Free;
end;
end;
Delphi Rest Api - hi_selamlar - 30-11-2017
(27-11-2017, Saat: 16:42)ismailkocacan Adlı Kullanıcıdan Alıntı: Çok eskiden ben bir deneme yapmıştım.Mantığını kavramanda yardımcı olabilir.
Burada da daha önce Kemal Ağabeyim ile yaptığımız örnek bir çalışma var.Bunlar sana fikir verebilir.
Paylaşım için teşekkürler.