Dahili ve harici API mimarisi

Çalıştığım şirket, yıllar içinde "organik olarak" büyüyen başarılı bir SaaS ürününü sürdürüyor. Mevcut ürünle veri paylaşacak bir dizi yeni ürünle hattı genişletmeyi planlıyoruz. Bunu desteklemek için, iş mantığını tek bir yerde birleştirmek istiyoruz: bir web hizmeti katmanı. WS katmanı aşağıdakiler tarafından kullanılacaktır:

• Web uygulamaları
• Verileri içe aktarmak için bir araç
• Diğer istemci yazılımlarıyla entegre etmek için bir araç (kendi başına bir API değil)

Ayrıca, müşterilerimiz tarafından kendi entegrasyonlarını oluşturmak için kullanabilen bir API oluşturmak istiyoruz. Aşağıdaki soru ile mücadele ediyoruz:

Dahili API (WS katmanı olarak da bilinir) ve harici API aynı olduğunda, kim tarafından yapılabileceğini kontrol etmek için güvenlik ve izin ayarlarıyla mı yoksa harici API'nin yalnızca dahili API'yı çağırdığı iki ayrı uygulama mı olmalıdır? başka herhangi bir uygulama gibi? Şu ana kadar yaptığımız tartışmalarda, onları ayırmanın daha güvenli olabileceği, ancak ek yük getireceği görülüyor.

Benzer bir durumda başkaları ne yaptı?

Kendi dogfood'ınızı yemek her zaman iyidir. Kimlik doğrulama ve yetkilendirme için bazı ek yükleri hesaba katsanız bile, bir API'nin bakımı ikiden daha kolay olmalıdır.

Aneurysm9 ile hemfikir olmama rağmen bazen sisteminizin tüm yeteneklerini ortaya çıkarmak istemezsiniz. Bu durumda iki API'ye sahip olmak tercih edilir ... AMA bu şekilde seçtiyseniz ... tüm ortak işlevlerin aynı API'yi paylaştığından emin olun, IE biri diğerinin genişletilmiş bir sürümü olmak yerine iki farklı kod kümeleri.

Bu şekilde, özel, hassas, deneysel çalışmanın ilerlemesi için kendinizinkini kendiniz kullanacaksınız ve yine de yeni API'ları çok fazla değiştirmeden yeni içerikleri yayınlamanıza ve kullanmanıza olanak tanır.

Bunu daha önce (birçok kez) karşılaştım ve tercih ettiğim şey:

BL'yi web sitesinden çıkarın. Web sitesini API'nın bir tüketicisi yapın. Web sitesini, API'nizin başka bir istemcisi olarak değerlendirin. API'niz hizmettir.

Kendinizi sadece web sitesi için özel API yöntemlerine ihtiyacınız olduğunu düşünüyorsanız, tekrar düşünün! Kaz için iyi ise, gander için iyidir. Web sitesi için gerçekten gerçekten özel bir işlevselliğe ihtiyacınız varsa, gerçekten bulduğunuz şeyin "kullanıcı profilinde" bir fark olduğunu ve bu nedenle API'nin "özel" işlevleri hala desteklemesi gereken bir durum olduğunu öneririm, ancak yetkilendirme yoluyla kontrol edebilir.

İkna olmadınız mı?

Paradigmayı bir adım daha ileri götürün ...

Telefon uygulaması bytecode'un yürütüldüğü, uygulama telefonda yaşadığı ve HTTP / JSON üzerinden API hizmetlerini kullandığı bir platformda çalışıyor

Web sitesi, HTML + Javascript'in yürütüldüğü, uygulama bir tarayıcıda yaşadığı ve HTTP / JSON üzerinden API hizmetlerini kullandığı bir platformda çalışan bir uygulamadır.

Benzer!

Bunu tabletlere, TV'lere, diğer telefon platformlarına, eklentilere, üçüncü taraf uygulamalarına, mashup'lara, ...

Çok sayıda farklı kullanıcı deneyimi ortak bir API'ya bağlı.

Uygulamanız API. Web sitesi sadece bir müşteridir.

Bir API kullanın

Hizmet API'sini bir REST katmanı olarak uyguluyorsanız, korunan yollara kimlik doğrulaması eklemeniz yeterlidir.

Muhtemelen çok fazla 'sihirde' pişirmeyen bir geliştirme çerçevesi kullanmak isteyeceksiniz. Bir sürü ters mühendislik olmadan rotaları doğrudan tanımlayabileceğiniz bir şey.

Node.js / Express, python / pilonlar, python / google uygulama motoru vb.

Kısa süre önce bunu bir REST / Datastore API'sı için Google App Engine'de uyguladım ve bunun daha kolay olabileceğini düşünmüyorum. Denetleyiciler sınıf olarak uygulanır ve sonraki HTTP istekleri (yani GET / POST / PUT / DELETE) bu sınıfların yöntemi olarak uygulanır. Dekoratör olarak temel yetkilendirmeyi uygulamayı başardım. Bu, bir isteğe kimlik doğrulama gereksinimi eklemeyi @basicAuth dekoratörünü eklemek kadar basit hale getirdi.

Bu şekilde, gelen GET isteklerini genel olarak bu model için aynı denetleyicide POST / PUT / DELETE isteklerine bir kimlik doğrulama gereksinimi ekleyebilirim.

REST'te nasıl konuşulacağını biliyorsanız, REST desteği zaten web sunucusuna doğal olarak pişirildiği için hayat çok daha kolay hale gelir (yani, HTTP sadece bir tür REST API'sidir). Kablo üzerinden çok fazla veri gönderiyorsanız şeffaf gzip sıkıştırmayı bile seçebilirsiniz.

İlk izlenimim bunun aynı API olması ve güvenliğinizin tamamen farklı bir katman üzerinde olması gerektiğidir. Belki bir web cephesi tarafından ele alınabilir?