SAP Gateway ile RestAPI Geliştirme – CRUDQ

Bir web hizmeti, bir elektronik cihaz tarafından başka bir elektronik cihaza sunulan ve World Wide Web üzerinden birbirleriyle iletişim kuran bir hizmettir. Bir Web hizmetinde, başlangıçta insandan makineye iletişim için tasarlanmış olan HTTP gibi Web teknolojisi, makineden makineye iletişim için, daha spesifik olarak XML ve JSON gibi makine tarafından okunabilir dosya formatlarının aktarılması için kullanılır. Uygulamada, web hizmeti tipik olarak, örneğin başka bir web sunucusu veya son kullanıcıya bir kullanıcı arayüzü sağlayan bir mobil uygulama tarafından kullanılan bir veritabanı sunucusuna nesne yönelimli web tabanlı bir arayüz sağlar.

ABAP dünyasında, web hizmeti geliştirmek çok kolaydır, sadece bir günde çok sayıda işlem içeren bir API oluşturabilirsiniz. Ancak teknoloji yığınlarındaki yeni gelişmeler ve değişiklikler size birçok farklı seçenek sunuyor. Örneğin, geliştirme senaryolarımızın çoğunda genellikle SOAP hizmetleri geliştiriyoruz. SAPUI5 veya Hybris Marketing gibi ürünlerdeki değişikliklerle birlikte SAP, SAP Gateway adını verdiği kendi Rest API geliştirme ortamını kullanmaya başladı.

SOAP (Simple Object Access Protocol) ve REST (Representational State Transfer) servisleri arasındaki temel farklar:

  1. Protokol:
    • SOAP, XML tabanlı bir protokol kullanır.
    • REST, genellikle XML veya JSON gibi hafif veri formatlarını kullanabilir, ancak protokol olarak spesifik bir gereklilik koymaz.
  2. Veri Formatı:
    • SOAP, genellikle XML formatında veri iletilir.
    • REST, XML veya JSON gibi farklı veri formatlarını destekler, ancak JSON daha yaygın olarak tercih edilir.
  3. Mimari Stil:
    • SOAP, genellikle RPC (Remote Procedure Call) tabanlı bir mimariyi destekler.
    • REST, kaynakları temsil eden bir mimari stile sahiptir ve stateless (durumsuz) bir iletişimi teşvik eder.
  4. Bağlam (Statefulness):
    • SOAP, stateful (durumlu) veya stateless (durumsuz) olabilir, ancak genellikle stateful uygulamalar için daha uygundur.
    • REST, stateless (durumsuz) bir yaklaşım benimser. Her istek, gerekli tüm bilgileri içermelidir ve sunucu, her isteği bağımsız olarak işler.
  5. Protokol ve Standartlar:
    • SOAP, belirli bir protokol ve standart seti (WS-Security, WS-ReliableMessaging gibi) tanımlar.
    • REST, HTTP protokolünü temel alır ve genellikle OAuth gibi genel güvenlik standartlarını kullanır.
  6. Performans:
    • SOAP, genellikle daha büyük mesaj boyutlarına ve daha karmaşık XML yapılarına sahip olabilir, bu da daha fazla bant genişliği kullanımına neden olabilir.
    • REST, genellikle daha hafif ve daha az karmaşık veri yapıları kullanır, bu da daha iyi performansa olanak tanır.
  7. Hata Kullanımı:
    • SOAP, spesifik hata durumları ve kodları ile ayrıntılı hata raporlama sağlar.
    • REST, genellikle HTTP durum kodları ve basit hata mesajları kullanır.
  8. Uygulama Alanı:
    • SOAP, genellikle büyük ve karmaşık iş uygulamaları için tercih edilir.
    • REST, genellikle web uygulamaları, mobil uygulamalar ve hafif uygulamalar için tercih edilir.
  9. WS- Standardları:*
    • SOAP, WS-* (Web Services) standardı altında bir dizi spesifikasyonu içerir.
    • REST, genellikle daha açık ve esnek standartlara dayanır.

Bu farklar, SOAP ve REST arasındaki temel ayrımları özetlemektedir. Seçim, projenin gereksinimlerine ve uygulama senaryosuna bağlı olarak yapılmalıdır.

SOAP ve REST hizmetleri arasındaki temel farkları görmek için aşağıdaki resmi inceleyebilirsiniz.

Başlıktan da görebileceğiniz gibi, REST servislerini kullanarak gerçekleştirebileceğiniz birkaç işlem vardır.

C(reate), R(ead), U(pdate), D(elete), Q(uery) en sık kullanılanlardır.

Mevcut iş senaryomuzda, iş ortaklarımızı bir mobil uygulamaya sunmamız gerektiğini varsayalım, böylece ya hepsini tüketebilirler ya da ortak kimliğini kullanarak ortakları filtreleyebilirler.

Öncelikle Data Dictionary – SE11 kullanarak bir veri yapısı tipi oluşturacağız. Bu veri yapısı ile api ile hangi verileri paylaşacağımızı belirleyeceğiz.

Ben bir yapı oluşturdum ve ‘ZMOBILE_MEMBERS’ olarak adlandırdım ve içine birkaç alan ekledim.

segw – SAP Gateway

T-kodunu girin ve Gateway’in ana penceresini göreceksiniz. Ardından ‘Yeni Proje Oluştur’a tıklayın.

Yapıyı, model verisine aktarıyoruz.

Yeni veri modelini içe aktarırken birkaç seçeneğin mevcut olduğunu görebilirsiniz. Modeli bir dosyadan içe aktarabilir veya RFC Fonksiyon Modülü arayüzünü kullanabilir veya hatta arama yardımcılarını kullanabilir ve ondan model oluşturabilirsiniz.

Bu durumda DDIC (Veri Sözlüğü) Yapı bölümünü kullanacağız.

Varlığınız için uygun bir ad girin ve sorgu işlemimizi yapabilmemiz için Varsayılan Varlık Kümesi Oluştur seçeneğini işaretleyin.

Şimdi gösterilmesini istediğiniz alanlar için seçim yapın.

Ve son olarak anahtar alanınızı belirleyin.

Her şey hazır. Şimdi servisimizi uygulamaya hazırız.

Hizmet uygulama sekmesinde daha önce bahsettiğimiz işlemleri göreceksiniz.

Entity sınıfımızın GetEntity( Read ) ve GetEntitySet( Query ) metotlarını uygulayacağız. Herhangi bir şey yapmadan önce kaydedin ve Generate Runtime Objects düğmesine tıklayın. – Beyaz-kırmızı desenli daire

Gateway şimdi veri sağlayıcı ve model sağlayıcı sınıflarımızı oluşturacak.

Şimdi Query işlemine sağ tıklayın ve ABAP workbench’e git seçeneğini seçin.

Veri sağlayıcı sınıfınız bazı verileri sağlamaya hazır. Ancak bir sorun var. Herhangi bir şey sağlamasını söylemediğimiz için çalışmıyor.

Düzenleme modunu açın ve MEMBERSSET_GET_ENTITYSEY yöntemini seçin, ardından yeniden tanımla’ya tıklayın.

Uygulamaya hazırız.

Verilerimizi almak için sadece birkaç satır kod yazacağım, filtre yok, hata işleme yok, her şeyin yolunda gideceğini varsayıyoruz.

  METHOD membersset_get_entityset.

    SELECT partner, addrcomm, name_first, name_last, crdat FROM but000
      INTO TABLE @DATA(lt_but000) UP TO 100 ROWS
      WHERE name_first NE @space
      AND name_last NE @space.

    IF lines( lt_but000 ) GT 0.
      "et_entityset is our exporting table with data
      APPEND LINES OF lt_but000 TO et_entityset.
    ENDIF.

  ENDMETHOD.

Kaydedin ve etkinleştirin.

Hizmetimizi denemeden önce, ağ geçidine kaydettirdik.

T kodunu girin -> /n/IWFND/MAINT_SERVICES ve hizmet ekle’ye tıklayın.

Hizmetinizi seçin ve ardından Seçili Hizmetleri Ekle düğmesine tıklayın.

Metadata başarıyla yüklendi açılır penceresini gördükten sonra, hizmetiniz artık kullanıma hazırdır.

Geri dönün, hizmetinizi bulun ve çift tıklayın. Ardından SAP Gateway Client düğmesine tıklayın.

Doğru hizmete erişmeye çalıştığınızdan emin olun.

/sap/opu/odata/sap/ZREST_MOBILE_BACKEND_SRV/?$format=xml

Bu url’yi Gateway Client kullanarak çalıştırırsanız, hizmetinizin meta verilerine erişebilirsiniz. Bazen, meta verilerinizi kullanarak servislerinizi tamponlamak isteyen farklı çerçeveler kullanan uygulamalar geliştirdiğinizde bu önemlidir. Servis hakkında ayrıntılı bilgiye ihtiyacınız olacaksa, URI Ekle seçeneğine tıklayın ve sap-documentation=all seçeneğini seçin.

Yürütmeden sonra hizmetinizle ilgili ayrıntılı bilgileri görebilirsiniz.

Uygulamamızın çalışıp çalışmadığını deneme zamanı 🙂

EntitySets butonuna tıklayın ve doğru entityset’i seçin.

Kullanabileceğimiz tüm seçeneklerin mevcut olduğunu görebilirsiniz, bizim durumumuzda GET yöntemini kullanacağız.

Biçimi json olarak değiştirin ve yürüt’e tıklayın.

İşe yarıyor! Artık verilerinizi istediğiniz herhangi bir araç veya dil ile ayrıştırabilirsiniz!

HTTP yöntemleri hakkında daha fazla bilgi edinmek istiyorsanız, şiddetle tavsiye ettiğim Mozilla Developer Network’ü inceleyebilirsiniz.

Yazı için Gürkan Yılmaz’a teşekkür ederim.

RestAPI Methodları ile ilgili genel bilgi

RESTful API’lar (Representational State Transfer), web servislerinin tasarımı için kullanılan bir mimari stildir. Bu API’lar, kaynaklar üzerinde temsil durumunu transfer etmeyi esas alır. REST API’lar, HTTP protokolü üzerinden çalışır ve genellikle CRUD (Create, Read, Update, Delete) operasyonlarını destekler. İşte REST API’larında sıkça kullanılan methodları detaylı olarak açıklarım:

  1. GET:
    • Açıklama: Kaynaklardan bir veya birkaçının okunması için kullanılır.
    • Kullanım Örneği: GET /users (Tüm kullanıcıları getir), GET /users/1 (ID’si 1 olan kullanıcıyı getir)
  2. POST:
    • Açıklama: Yeni bir kaynak oluşturmak için kullanılır.
    • Kullanım Örneği: POST /users (Yeni bir kullanıcı oluşturmak için)
  3. PUT:
    • Açıklama: Var olan bir kaynağın tamamen güncellenmesi için kullanılır. Kaynak varsa günceller, yoksa yeni bir kaynak oluşturabilir.
    • Kullanım Örneği: PUT /users/1 (ID’si 1 olan kullanıcıyı güncelle)
  4. PATCH:
    • Açıklama: Var olan bir kaynağın kısmi güncellenmesi için kullanılır. Yalnızca belirli alanları günceller.
    • Kullanım Örneği: PATCH /users/1 (ID’si 1 olan kullanıcının belirli alanlarını güncelle)
  5. DELETE:
    • Açıklama: Belirli bir kaynağı silmek için kullanılır.
    • Kullanım Örneği: DELETE /users/1 (ID’si 1 olan kullanıcıyı sil)
  6. OPTIONS:
    • Açıklama: Bir kaynağın desteklediği methodları almak veya bir isteğin geçerli olup olmadığını kontrol etmek için kullanılır.
    • Kullanım Örneği: OPTIONS /users (Kullanıcı kaynakları üzerinde desteklenen methodları al)
  7. HEAD:
    • Açıklama: GET methodu gibi davranır, ancak sadece başlık bilgilerini döndürür. Kaynağın içeriğini taşımaz, sadece başlık bilgileriyle cevap verir.
    • Kullanım Örneği: HEAD /users (Tüm kullanıcıları getirmek için, ancak sadece başlık bilgilerini almak istiyorsanız)
  8. GET (with Query Parameters):
    • Açıklama: Query parametreleri ile birlikte kullanılarak, kaynakları filtrelemek veya sıralamak için kullanılır.
    • Kullanım Örneği: GET /users?status=active (Durumu “active” olan tüm kullanıcıları getir)

Bu HTTP methodları, RESTful API’ların temelini oluşturur ve genellikle CRUD operasyonlarıyla ilişkilidir. Bu methodlar, web uygulamalarında veri manipülasyonu ve iletişimi için kullanılan güçlü araçlardır.

SOAP ve REST, farklı avantajlar ve dezavantajlara sahip iki farklı web servis protokolüdür. İşte her iki protokolün avantajları ve dezavantajları:

SOAP Avantajları:

  1. Standartlar ve Şemalar:
    • SOAP, belirli bir standart ve şema setine sahiptir. Bu, veri yapılarının ve iletişim kurallarının belirli bir standart üzerinde olmasını sağlar.
  2. Güvenlik:
    • SOAP, WS-Security gibi güvenlik standartlarını destekler. Bu, veri iletimi sırasında şifreleme ve kimlik doğrulama gibi güvenlik önlemlerini sağlar.
  3. Transaksiyon ve ACID Desteği:
    • SOAP, işlemleri gruplandırma ve ACID (Atomicity, Consistency, Isolation, Durability) transaksiyonları gibi işlem yönetimi özelliklerini destekler.
  4. Uzun Ömürlülük ve Uyumluluk:
    • SOAP, daha önce kullanılan ve şu anda kullanılan eski sistemlerle uyumlu olabilir. Bu, uzun ömürlülük ve mevcut sistemlere entegrasyon açısından avantaj sağlar.

SOAP Dezavantajları:

  1. Karmaşıklık ve Ağırlık:
    • SOAP, genellikle XML tabanlı mesajları kullanır ve bu da mesajların ağırlığını artırabilir. Karmaşıklığı ve büyüklüğü, bazı durumlarda performans sorunlarına neden olabilir.
  2. Esneklik ve Okunabilirlik:
    • SOAP, genellikle daha az okunabilir ve esnek değildir. Veri formatı olarak XML kullanılması, okunabilirlik açısından REST’e kıyasla dezavantajlı olabilir.

REST Avantajları:

  1. Hafif ve Hızlı:
    • REST, genellikle JSON gibi hafif veri formatlarını kullanır ve bu da veri iletimini hızlandırabilir. Daha küçük veri boyutları, daha iyi performans sağlar.
  2. Esneklik ve Okunabilirlik:
    • REST, genellikle daha okunabilir ve esnek bir yapıya sahiptir. JSON kullanımı, verinin daha açık ve anlaşılır olmasını sağlar.
  3. Statelessness (Durumsuz):
    • REST, stateless bir yaklaşım benimser. Bu, her isteğin kendi içinde bağımsız olmasını sağlar ve sunucu tarafındaki durumu minimuma indirir.
  4. Geliştirici Dostu:
    • REST, basit HTTP protokolü üzerine inşa edilmiştir ve bu da geliştiriciler için kullanımını kolaylaştırır. HTTP protokolünü kullanarak mevcut araçlar ve kütüphanelerle uyumlu çalışabilir.

REST Dezavantajları:

  1. Güvenlik:
    • REST, genellikle SOAP’a kıyasla daha az güvenlik özelliği içerir. Bu nedenle, güvenlik önlemleri uygulanırken dikkat edilmesi önemlidir.
  2. Standartsızlık:
    • REST, standart bir şemaya veya spesifik bir protokole dayanmaz. Bu durum, bazen belirsizlik ve uyumsuzluk sorunlarına yol açabilir.
  3. Transaksiyon Desteği:
    • REST, SOAP’a göre daha sınırlı bir işlem yönetimi sağlar. ACID transaksiyonları gibi karmaşık işlemleri desteklemez.

Her iki protokolün avantajları ve dezavantajları, uygulama gereksinimlerine ve kullanım senaryolarına bağlı olarak değerlendirilmelidir.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir