Bir api oluştururken küçük işlevler ve birçok çağrı mı, birkaç çağrı ve büyük işlevler mi yapmalıyım?

Bakımını yaptığım ray platformum var. Bunun üzerine inşa edilmiş birçok farklı web uygulaması vardır. Ancak şimdi bir müşteri, kullanıcıları sitelerinde tutabilmeleri için bir API istiyor, ancak sahip olduğumuz bazı otomatik görevlerden yararlanabiliyor.

Platform, sigorta uygulamaları oluşturmak için kullanılır ve çevrimiçi satın alınmalarına izin verir ve ayrıca poliçenizle ilgili belgeleri indirmek için yollar sunar.

Yani API oluştururken sorum şu:

Ben bir çok şey yapmak zorunda olduğunda, böyle validatebir oluşturmak user, user profileve policy, hemen hemen aynı anda. 4 ayrı API çağrısı yapıp istemcinin kendi tarafında 4 çağrı yapmasını sağlamalı mıyım. YA DA müşteriyi doğrulayan ve aynı anda bu şeylerin hepsini yaratan birçok parametreyi hariç tutan ve istemciyi basitleştiren bir çağrı yapmalı mıyım?

Müşteri, bu durumda, gerekli tüm bilgileri aynı anda alır, bu nedenle uygulamalarında durakladığı bir doğal akış olduğu gibi değildir ve platformuma bir API çağrısı yapabilirler.

Daha önce pek çok API kullanarak müşteri tarafında olmak, benim bağırsak müşteri için mümkün olduğunca basit hale getirmek ve sadece bir arama yapmaktır. Ancak bu, functionsAPI'da oldukça büyük , ki ben de hayranı değilim.

Bununla başa çıkmamı nasıl önerirsin?

Not olarak, müşterilere kendi tarafında karmaşık bir API uygulama becerisinden çok emin değilim.

İkisine de ne dersin? Sistemin işlevlerini ortaya çıkaran bir " düşük seviye " (tabiri caizse) API'ye sahip olun ve bir müşterinin yapmak isteyebileceği hizmetleri sunan başka bir "katmana" sahip olun. Bu katman, gerekli olan düşük seviye API'leri kullanır, ancak istemci bunları isterse yine de ortaya çıkar.

GÜNCELLEME: Başkalarının yaptığı bazı önemli noktaları ve yorumları da dahil etmek.

1. İstemcinin daha küçük API yöntemlerinden birini çağırması gerekip gerekmediğini göz önünde bulundurun; örneğin, createUser'ı çağırmadan createUserProfile'i çağırmak mümkün mü? Eğer değilse o zaman bu yöntemi gösterme. Teşekkürler NoobsArePeople2

2. Basit ama mükemmel bir nokta. Bir API'de bir şeyi ortaya çıkarmanın kilit noktası - hiçbir zaman açıklanamazsınız. Her şeyi açığa vurmak yerine çalışmak ve daha sonra genişletmek için gereken en düşük seviyeyi gösterin ve ... peki, sonra çıplak ve değişiklik yapmak utanç verici ve garip olabilir . Teşekkürler MichaelT

Bence yanlış bakıyorsun. Büyük endişelenme | küçük aramalar veya bir sürü | birkaç görüşme

İş nesneleri ve gerçekleştirilebilecek eylemler hakkında düşünün | için | bu nesnelere karşı.

Sende:

• Kullanıcılar
• Politikalar
• Oranlar
• ...

Bu nedenle, bu nesnelerin etrafında API çağrıları oluşturmalısınız.

• User.Create
• User.UpdatePassword
• Policy.Validate
• ...

Fikir, iş nesnelerine ve onların eylemlerine dayanarak atomik veya atomik yakın işlemler oluşturmaktır. Bu, tasarım ve kodlamayı kolaylaştıracaktır - iş nesnesinin yapması gereken şeyi yapan ve programcıların zihinsel modeline veya beklentilerine uyan çağrıları kolaylaştıracaktır. Programcılar veya mimarlar iş analistleriyle gereksinimleri görüşürken, hepsi aynı terminolojiyi ve genel işlem akışını kullanabilirler.

Daha büyük, hepsi bir arada telefon görüşmelerindeki sorun yan etki riskidir. Policy.Create ayrıca bir Kullanıcı ortaya çıkarır ve başka bir eylemi tetiklerse, bu programcıların beklentilerini bozar. Aynı şekilde, çok sayıda küçük çağrı programlayıcıyı "tek" bir işletme işlemi gerçekleştirmek için A ve sonra B ve sonra C olarak çağırmayı hatırlamaya zorlar.

Çağrıları nasıl adlandıracağınız Rails ve destek web servislerinin destekleyeceği temel olacaktır.

Daha kuralcı olmak için, bu, birkaç parametre alan ve arka uçta müşteriye gizlenmiş birden fazla çağrı yapabilen bazı çağrılar yaratacaktır. Ayrıca, API'nin temel rutine göre bir sarıcıdan biraz daha fazlası olduğu oldukça hızlı / basit çağrılarla biteceksiniz.

Bağırsak hissetmenin doğru olduğunu düşünüyorum - API'yi tüketiciler için basitleştirin. Bir dereceye kadar, Tüketici Odaklı Sözleşmelerin arkasındaki felsefe budur .

Daha spesifik olarak, API uygun iş kullanımı durumlarını ortaya çıkarmalıdır. Eldeki işletme alanını düşünün - bu düşük seviyeli işlevlere gerçekten ihtiyaç var mı? Onları içine almanın sakıncası nedir? API'deki büyük işlevler kendi başlarına bir sorun değildir. Bir sorun, tüketici müdahalesine izin vermek için bölümlendirilmesi gerekebilecek işlemleri büyük bir fonksiyon dizisi halinde yapmasıdır.

Şahsen ben şu API’leri seviyorum:

1. Yaygın kullanım durumlarının kolayca gerçekleştirilebileceği şekilde optimize edilmiştir
2. CRUD işlemleri ile ilgili çağrılar parti yönelimli veya parti sürümleri
3. Yansıtmaya izin verir (diğer bilgisayar dilleri için eklenti veya ciltleme yazan kişiler bu işlemi otomatikleştirebilir)