Özel bir şablona benzemeyen, kişiselleştirilmiş bir mağaza ön yüzünde (storefront) alışveriş yaptıysanız, muhtemelen arkasında başsız (headless) bir e-ticaret API'si çalışıyordu. Başsız bir e-ticaret API'si, herhangi bir mağaza ön yüzünün ürünleri okuyabilmesi, sepet oluşturabilmesi ve yerleşik bir temaya bağlı kalmadan sipariş verebilmesi için bir e-ticaret arka ucunun (backend) sunduğu arayüzdür. Bu açıklayıcı makale, bunun ne anlama geldiğini, birleştirilebilir e-ticaret (composable commerce) ve MACH ile nasıl ilişkili olduğunu ve mağaza ön yüzünüz ile iş ortağı ekiplerinizin neden bu API sözleşmesiyle ayakta kaldığını veya başarısız olduğunu ele alıyor. Bu, yazılımın başsız hale geldiği ve API'nizin artık bir ürün olduğu fikrine dayanıyor.
E-ticarette “başsız” ne anlama geliyor?
Geleneksel e-ticaret platformları tek bir parça halinde sunulur. Ürün kataloğu, sepet, ödeme ve bunları oluşturan HTML sayfalarının tümü aynı sistemde bulunur. Temasını belirlersiniz, ince ayar yapar ve yayınlarsınız.
Başsız e-ticaret bunu ikiye ayırır. Genellikle e-ticaret motoru olarak adlandırılan arka uç (backend), katalog, fiyatlandırma, envanter, sepet ve sipariş mantığını tutar. Mağaza ön yüzünüz olan ön uç (frontend), istediğiniz şekilde oluşturduğunuz ayrı bir uygulama haline gelir. Onları birbirine bağlayan tek şey bir API'dir.
Dolayısıyla “baş”, sunum katmanıdır. Başsız olmak, sabit başlığı kaldırmak ve bunun yerine gövdeyi, yani e-ticaret mantığını bir API aracılığıyla ifşa etmek anlamına gelir. Bir React sitesi, yerel bir mobil uygulama, akıllı buzdolabı ekranı veya bir sesli asistan, hepsi aynı API'yi konuştukları için aynı arka uç ile iletişim kurabilir.
Bu ayrıştırma (decoupling) tüm meselenin özüdür. Ön uç ekibiniz kendi çerçevesini seçer ve kendi programına göre yayınlar. Arka uç ekibi e-ticaret kurallarının sahibidir. API, aralarındaki çizgidir.
Dezavantajı ise daha fazla iş yükü üstlenmenizdir. Geleneksel bir platform size kullanıma hazır bir mağaza sunar. Başsız olmak, mağaza ön yüzünü kendinizin oluşturup barındırmanız anlamına gelir, bu nedenle esneklik mühendislik maliyetiyle birlikte gelir. Ekipler, hazır bir tema ihtiyaç duydukları deneyimi sağlayamadığında veya tek bir arka uçtan birden fazla kanala hizmet vermek istediklerinde başsız mimariyi tercih ederler.
Başsız (Headless) vs Birleştirilebilir (Composable) vs MACH
Bu üç terim birbirinin yerine kullanılsa da farklı kapsamları tanımlarlar. İşte dürüst bir döküm.
| Terim | Ne tanımlar | Kapsam |
|---|---|---|
| Başsız e-ticaret | Tek bir e-ticaret arka ucundan API ile bağlı olarak ayrılmış ön uç | Tek arka uç, bir veya çoklu ön uçlar |
| Birleştirilebilir e-ticaret | Tüm yığın, değiştirilebilir en iyi hizmetlere bölünmüştür (katalog, arama, ödemeler, PIM, OMS) | Bir araya getirilmiş birçok bağımsız hizmet |
| MACH | Birleştirilebilir yığınların eğilimli olduğu mimari prensipler bütünü | Bir felsefe, bir ürün değil |
Başsız, dar kapsamlı bir durumdur. Mağaza ön yüzü, bir API aracılığıyla konuşabildiği sürece, tek bir monolitik arka uçla bile başsız olabilirsiniz.
Birleştirilebilir e-ticaret daha ileri gider. Tek bir arka uç yerine, bağımsız hizmetleri bir araya getirir ve her iş için en iyi aracı seçersiniz. Bir satıcıdan arama, başka bir satıcıdan ödemeler, ayrı bir ürün bilgi yöneticisi. Her biri kendi API'sine sahip kendi hizmetidir ve bunları tek bir deneyim halinde birleştirirsiniz.
MACH, çoğu birleştirilebilir yığının arkasındaki prensipler bütünüdür. 2020'de kurulan bir endüstri grubu olan MACH Alliance'a göre, MACH; Mikro hizmetler (Microservices), API-öncelikli (API-first), Bulut yerel SaaS (Cloud-native SaaS) ve Başsız (Headless) kelimelerinin baş harflerinden oluşur. API-öncelikli kavramının tam ortada yer aldığına dikkat edin. Bir MACH dünyasında, API yan bir özellik değildir. Parçaların birbiriyle konuşmasının tek yoludur; bu da API'nizi bir ürün olarak görmenin arkasındaki mantıkla aynıdır.
Başsız bir e-ticaret API'si aslında neyi ifşa eder?
Tam şekil platforma göre değişmekle birlikte, çoğu başsız e-ticaret API'si aynı temel görevleri kapsar:
- Katalog ve ürünler. Mağaza ön yüzünün listelemeleri ve detay sayfalarını oluşturabilmesi için ürünleri, varyantları, koleksiyonları ve medyayı okuyun.
- Arama ve göz atma. Kataloğu sorgulayın, filtreleyin ve sıralayın.
- Sepet ve ödeme. Bir sepet oluşturun, satır öğeleri ekleyin ve kaldırın, indirimler uygulayın ve ödemeye doğru ilerleyin.
- Müşteriler. Oturum açın, hesapları yönetin ve sipariş geçmişini takip edin.
- Envanter ve fiyatlandırma. Stok seviyelerini ve doğru bağlam için doğru fiyatı ortaya çıkarın.
Bazı platformlar bunları halka açık bir mağaza ön yüzü API'sine ve arka ofis işleri için ayrı bir yönetici API'sine ayırır. Mağaza ön yüzü API'si yoğun olarak okuma odaklı ve müşteri odaklıdır. Yönetici API'si katalog düzenlemelerini, sipariş yönetimini ve yapılandırmayı yönetir.
Protokol de önemlidir. Birçok başsız e-ticaret API'si GraphQL'dir, bu da mağaza ön yüzünün tek bir gidiş-dönüşte tam olarak ihtiyaç duyduğu alanları istemesine olanak tanır. Diğerleri REST'tir ve bazı platformlar her ikisini de sunar. Karşılıklı değiş tokuşları değerlendiriyorsanız, REST vs GraphQL makalesine bakın.
Başlıca platformlar
Başsız e-ticaret alanı kabaca SaaS motorları ve açık kaynak motorları olarak ikiye ayrılır. Karşılaşacağınız birkaç isim:
- commercetools. Kurucu bir MACH Alliance üyesi ve en çok atıfta bulunulan birleştirilebilir e-ticaret platformlarından biridir. Tasarımı itibarıyla API-öncelikli ve bulut-yereldir.
- Shopify. Storefront API'si aracılığıyla başsız yapılar sunar ve bunu tüketmek için bir React çerçevesi olarak Hydrogen'i kullanır. Halihazırda Shopify dünyasındaysanız, Shopify API eğitimimiz iyi bir başlangıç noktasıdır.
- BigCommerce. Kataloğunun üzerinde GraphQL Storefront ve Checkout API'leri ile başsız modu destekler. BigCommerce API'lerini kullanma kılavuzumuza bakın.
- Saleor. Python ve Django üzerine kurulu, açık kaynaklı, GraphQL-öncelikli bir motordur.
- Medusa. Node.js ve TypeScript üzerine kurulu, açık kaynaklı bir motordur, tam arka uç kontrolü isteyen JavaScript ekipleri arasında popülerdir.
Fiyatlandırma, barındırma modelleri ve API kapsamı değiştiği için taahhütte bulunmadan önce platform özelliklerini doğrulayın. Hepsinin ortak noktası aynıdır: motor, e-ticaret mantığını bir API aracılığıyla ifşa eder ve siz başlığı (ön yüzü) inşa edersiniz.
Ekipler neden e-ticaret API sözleşmesine bağlıdır?
Mağaza ön yüzü ayrıştırıldığında, API bir tesisat olmaktan çıkar ve herkesin üzerinde çalıştığı bir anlaşmaya dönüşür. Başsızlık burada gerçek anlamını bulur.
Ön uç ekibiniz, bir ürün yanıtının tam şeklini bilmeden bir ürün sayfası yayınlayamaz. İş ortağı entegrasyonlarınız, bir sadakat uygulaması, bir vergi hizmeti, bir pazar yeri beslemesi, hepsi aynı uç noktalara bağlanır. Bir mobil ekip, web ekibiyle aynı sözleşmeyi kullanır. Yanıt şekli uyarı olmaksızın değişirse, bu tüketicilerin her biri aynı anda bozulabilir.
İşte risk ve fırsat budur. Açık, istikrarlı, iyi belgelenmiş bir e-ticaret API sözleşmesi, bağımsız ekiplerin birbirine engel olmadan hızlı hareket etmesini sağlar. Belirsiz veya sürüklenen bir sözleşme, her sürümü bir koordinasyon telaşına dönüştürür. Sözleşme bir üründür, bu nedenle kendisiyle aynı özeni hak eder; buna, yayınlanmadan önce bozucu değişiklikleri yakalamak için sözleşme testi de dahildir.
Sürümleme de anlaşmanın bir parçasıdır. Bir ürün yanıtını değiştirmeniz veya bir alanı yeniden adlandırmanız gerektiğinde, sadece uç noktayı düzenleyip umut edemezsiniz. Kontrol edemediğiniz tüketiciler bunu okuyor. Bu nedenle başsız ekipler, sözleşmeyi herkese açık bir taahhüt olarak görür: mümkün olduğunca ek değişiklikler, net kullanımdan kaldırma pencereleri ve bir iş ortağının entegrasyonuna ulaşmadan önce herhangi bir bozulmayı işaretleyen testler.
Apidog nerede devreye giriyor?
Apidog mağazanızı çalıştırmaz. Bir e-ticaret motoru, bir CMS veya bir ağ geçidi değildir ve yığınınızı başsız veya birleştirilebilir hale getirmez. Yaptığı şey, tüm bunların API-öncelikli sütununa sahip çıkmaktır: diğer her şeyin bağlı olduğu sözleşmeyi tasarladığınız, test ettiğiniz, taklit ettiğiniz (mock) ve belgelediğiniz katman.
Bu, başsız e-ticaret çalışmalarına net bir şekilde karşılık gelir:
- Önce sözleşmeyi tasarlayın. Kod yazılmadan önce mağaza ön yüzü veya yönetici API'sini Apidog'da bir OpenAPI spesifikasyonu olarak modelleyin, böylece ön uç ve arka uç baştan şekil üzerinde anlaşsın.
- Arka uç hazır olmadan önce taklit edin (mock). Spesifikasyondan bir taklit sunucu başlatın, böylece e-ticaret motoru hala kurulurken mağaza ön yüzü ekibiniz gerçekçi ürün ve sepet yanıtlarına karşı geliştirme yapar. Bu, ayrıştırma vaadinin pratiğe dökülmesidir ve daha fazlasını taklit API açıklayıcımızda okuyabilirsiniz.
- CI'da sözleşmeyi test edin. Apidog CLI, API testlerinizi GUI olmadan, bir işlem hattına uyan başsız test yürütmesiyle çalıştırır. Bu, başsız e-ticaretle gerçek bir kavramsal uyum içindedir: ön uca gerek yok, sadece sözleşme doğrulanır.
- İş ortakları için belgeleyin. Otomatik oluşturulan, etkileşimli belgeler, mağaza ön yüzü ve iş ortağı ekiplerinize entegre ettikleri API için tek bir doğru kaynak sağlar.
API tek arayüz haline geldiğinde bunun neden önemli olduğuna daha derinlemesine bakmak için, yazılım başsız hale geliyor ve API'niz artık bir ürün makalesine bakın. İş akışını denemek isterseniz, Apidog'u indirin ve mevcut bir spesifikasyonu içe aktarın.
Sıkça sorulan sorular
Başsız e-ticaret, birleştirilebilir e-ticaret ile aynı mıdır?
Hayır. Başsız e-ticaret, mağaza ön yüzünü tek bir e-ticaret arka ucundan bir API aracılığıyla ayırır. Birleştirilebilir e-ticaret daha ileri gider ve her biri kendi API'sine sahip birçok bağımsız, alanının en iyisi hizmeti tek bir deneyimde birleştirir. Her birleştirilebilir yığın başsızdır, ancak tek bir monolitik arka uca sahip başsız bir kurulum mutlaka birleştirilebilir değildir.
Başsız bir e-ticaret API'si için GraphQL'e ihtiyacım var mı?
Hayır. GraphQL yaygındır çünkü mağaza ön yüzünün tek bir çağrıda tam olarak ihtiyaç duyduğu alanları istemesine olanak tanır, bu da ürün ve sepet oluşturma için oldukça uygundur. Ancak birçok başsız e-ticaret API'si REST kullanır ve bazı platformlar her ikisini de sunar. Protokol, sözleşmenin istikrarlı ve belgelenmiş olmasından daha az önemlidir.
Arka uç oluşturulmadan önce başsız bir e-ticaret API'sini test edebilir miyim?
Evet, ve bu, tasarım-öncelikli olmanın ana nedenlerinden biridir. API sözleşmesini bir spesifikasyon olarak modellerseniz, gerçekçi yanıtlar döndüren bir taklit sunucu oluşturabilirsiniz. Mağaza ön yüzü ekibiniz, e-ticaret motoru hala geliştirilirken taklit sunucuya karşı geliştirme ve test yapar, ardından daha sonra gerçek uç noktalara geçer.
MACH Alliance nedir?
MACH Alliance, 2020'de kurulan, Mikro hizmetler (Microservices), API-öncelikli (API-first), Bulut yerel SaaS (Cloud-native SaaS) ve Başsız (Headless) prensipleri üzerine inşa edilmiş açık, alanının en iyisi teknoloji yığınlarını teşvik etmek için oluşturulmuş bir endüstri grubudur. commercetools gibi satıcılar kurucu üyelerdir. MACH, satın aldığınız tek bir ürün değil, bir dizi mimari prensiptir.
Sözleşme mağazadır
Başsız e-ticaret, değeri temadan API'ye taşır. Mağaza ön yüzü ayrıştırıldığında, e-ticaret API'si ön uç, mobil ve iş ortağı ekiplerinizin üzerinde gerçekte çalıştığı şeydir. Birleştirilebilir e-ticaret ve MACH, API-öncelikli olmayı isteğe bağlı bir özellikten ziyade temel bir prensip haline getirerek bunu daha da ileri götürür.
Bunların hiçbiri Apidog'a bağlı değildir, ancak sözleşmenin kalitesi onu tasarlamak, taklit etmek, test etmek ve belgelemek için bir yerden fayda sağlar. Başsız projeniz bu yöne gidiyorsa, Apidog, alttaki e-ticaret motoru gibi davranmadan size bu katmanı sunar.