Sihirbazlı web sayfaları için REST API tasarımı

11

Sihirbaz biçiminde bir web sayfam var. API'ya gönderme düğmesi sihirbazın 4. adımında olacaktır. Ancak sihirbazda bir sonraki adıma geçmeden önce girilen verilerin veritabanında saklanmasını istiyorum. Ayrıca tek sekmeli sayfalar için REST API çalışmasını istiyorum.

Bu yüzden eylem parametresi eylem = taslak veya göndermek için API tasarlanmış. Eylem taslaksa, sadece belirli alanlar zorunludur. İşlem gönderilirse, tüm alanlar zorunludur. REST API'nin hizmet katmanındaki doğrulamalar query parametresine göre yapılacaktır. Belgedeki if / else maddelerini açıkça belirtmem gerekiyor gibi görünüyor. Bu RESTful tasarımının kabul edilebilir bir formu mudur? Bu gereksinimlerle en iyi tasarım ne olabilir?

design rest

— TechCrunch
kaynak

3

Geçici verilerin neden DB'de saklanması gerekir?

— Dan1701

2

@ Dan1701: böylece sihirbazı başka bir makineden devam ettirebilirsiniz. Uzun ve karmaşık formları doldururken, kullanıcının gerekli tüm verileri hazır bulundurmayabileceği veya kullanıcının farklı yerlerden yüklemek için ek dosyalar toplaması gerekebileceğinden, gerekli tüm verilerin tamamlanması birkaç gün sürebilir. Farklı bir cihazdan devam edebiliyorsanız, cep telefonundan bir fotoğraf yüklemek için sihirbazı yükleyebilir ve masaüstünde gerçek bir klavyeyle uzun bir açıklama / argüman yazmaya devam edebilirsiniz.

— Lie Ryan

Bu durumda, @ guillaume31'in cevabının mantıklı olduğunu düşünüyorum.

— Dan1701

7

Sunucuda sihirbaz adımları arasında bir şeyleri devam ettirmek istediğiniz için, her adımı ayrı bir kaynak olarak kabul etmek tamamen kabul edilebilir görünüyor. Bu çizgiler boyunca bir şey:

POST /wizard/123/step1
POST /wizard/123/step2
POST /wizard/123/step3

Yanıtta hiper ortam bağlantıları ekleyerek, istemciyi bu adımdan sonra neler yapabileceği konusunda bilgilendirebilirsiniz - ara adımlar için ileri veya geri gidin ve son adım için hiçbir şey yapmayın. Bunun bir örneğini burada Şekil 5'te görebilirsiniz .

— guillaume31
kaynak

UI için Angular kullanıyorum. Bu yüzden devlet makinesinin ne kadar yardımcı olduğundan emin değilim. Ama adım tabanlı kaynak başka bir tablo yönetmek daha anlamlı gibi görünüyor. Ayrıca, her şeyi tek bir adımda sunabilmeliyim. Bugün bu tasarım üzerinde bir şans verecek. Yardım için teşekkürler.

— TechCrunch

Rica ederim. Bu arada, "iki tablo" yaklaşımı bu konuda birbirini dışlamaz. Adım başına bir HTTP kaynağına sahip olmak, veritabanı şemasını değil, uygulama sunucusunda nesne modelinizi gerektirmez. Bu sadece bir Web temsilidir.

— guillaume31

1

@TechCrunch Temel olarak Guillaume, formu temsil eden nesnenin / tablonun, her adımda modelin bir kısmının kaydedildiği parçalara ayrılabileceği anlamına gelir. Aslında, her "adımın" tüm modelin bir parçası için bir form olmasını sağlayabilirsiniz . Ve bu yaklaşımı benimserseniz, aslında mimariyi inanılmaz derecede basitleştirir. Sunucuya gönderilen her POST aynı modeli oluşturur (oluşturur veya günceller) ve her bir GET aynı modeli yükler ve her adım anlamsal olarak anlamlı olan (bir araya ait) alan kümelerini doldurmak için bir form olacaktır. Ve sadece model için bir boole var in_progressveya draft.

— Chris Cirefice

3

Bir süre önce benzer bir şey yapmam gerekiyordu ve aşağıda neyle sonuçlandığımız açıklanıyor.

İki masamız var, Item ve UnfinishedItem. Kullanıcı verileri sihirbazla doldurduğunda, veriler UnfinishedItem tablosunda saklanır. Her sihirbaz adımında, sunucu bu adım sırasında girilen verileri doğrular. Kullanıcı sihirbazla işini bitirdiğinde, sihirbaz gönderilecek tüm verileri gösteren bir onay sayfasında gizli / salt okunur bir form oluşturur. Kullanıcı bu sayfayı inceleyebilir ve hataları düzeltmek için ilgili adıma geri dönebilir. Kullanıcı girdilerinden memnun kaldığında, kullanıcı gönder'i tıklatır ve sihirbaz gizli / salt okunur form alanlarındaki tüm verileri API sunucusuna gönderir. API sunucusu bu isteği işlediğinde, sihirbazın her adımı sırasında yaptığı tüm doğrulamaları yeniden çalıştırır ve tek tek adımlara uymayan ek doğrulamalar gerçekleştirir (örn. Genel doğrulamalar, pahalı doğrulamalar).

İki tablo yaklaşımının avantajları:

veritabanında, Öğe tablosunda UnfinishedItem tablosundan daha sıkı kısıtlamalar olabilir; sihirbaz tamamlandığında gerçekten gerekli olacak isteğe bağlı sütunlara sahip olmanız gerekmez.
Bitmemiş Öğeler'deki toplam sorgular, UnfinishedItems'i hariç tutmayı hatırlamanız gerekmediğinden raporlama için daha kolaydır. Bizim durumumuzda, Item ve UnfinishedItems arasında toplu sorgular yapmamıza gerek yoktu, bu yüzden bu bir sorun değil.

Dezavantaj:

Doğrulama mantığının kopyalanmasına eğilimlidir. Kullandığımız web çerçevesi Django, Item ve UnfinishedItem'de farklı olmamız gereken kısıtlamaları değiştirmek için biraz meta büyü ile model mirasını kullandığımız için bunu biraz daha katlanılabilir hale getiriyor. Django, veritabanının çoğunu oluşturur ve modelden doğrulama işlemini gerçekleştirir ve bunun üzerine yalnızca birkaç ek doğrulama yapmamız gerekir.

Düşündüğüm diğer olasılıklar ve neden onlarla gitmedik:

verileri çerezlere veya yerel depolama alanına kaydetme: kullanıcı farklı bir cihazdan veya tarayıcı geçmişini silmeye devam edemez
UnfinishedItem'i veritabanında veya ikincil veri deposunda yapılandırılmamış veriler (örn. JSON) olarak saklayın: Ayrıştırma mantığını tanımlamam gerekiyor ve Django'nun otomatik modeli / form doğrulamasını kullanamıyorum.
istemci tarafında adım başına doğrulamayı yapın: Python / Django ve JavaScript arasında doğrulama mantığını çoğaltmam gerekecek.

— Yalan Ryan
kaynak

1

'Taslak' tip modellerde ve 'bitmiş' modellerde doğrulamalara işaret etmek için +1 Bunu düşünmedim ve dikkate alınması gereken önemli bir nokta. Aksi takdirde, iftüm onaylarınızda taslak durumunu kontrol eden bir sürü ifadeniz olabilir, bu da iyi olmaz. Rağmen Ruby on Rails gibi bazı çok gelişmiş çerçeveler doğru uygulanırsa bu sorunu önemli ölçüde basitleştirebilir.

— Chris Cirefice

1

Bunu @ guillauma31 ve @Lie Ryan'ın çözümlerinin karışımına benzer bir şekilde uyguladım.

İşte temel kavramlar:

Tamamlanana kadar kısmen kalıcı olabilecek 3 adımlı bir sihirbaz vardır.
Her adım (örn .: o kendi kaynağa sahip /users/:id_user/profile/step_1, .../step_2vs.)
Her adımda, veri ve tamamlanma durumu GET istekleri yoluyla alınabilir ve PATCH istekleri ile devam ettirilebilir.
Her kaynağın girilen veriler için kendi doğrulama kuralları vardır.
Her adım, diziyi garanti etmek için bir sonraki adımın girişinde kullanılması gereken bir anahtar döndürür. Bir kez kullanıldığında veya yeni bir tane oluşturulduğunda, bu jetonun süresi dolar.
Son adımda, veritabanında gerekli tüm veriler var ve bir onay ekranı görüntüleniyor. Bu onay, verileri tam olarak işaretlemek için başka bir kaynak çağırır (örn .:) .../profile/confirm. Bu kaynağın tüm verileri tekrar alması gerekmez. Verileri yalnızca doğru ve eksiksiz olarak işaretler.
Birkaç günden fazla olmayan bu eksik girişleri silen planlanmış bir rutin var.

Ön uç adamlar, sihirbazın ileri geri akışını çalıştırmak için belirteçlere dikkat etmelidir.

API vatansız ve atomiktir.

"Tek adımda sihirbazın" bu kurulumla çalışmasını sağlamak için, belirteç akışını kaldırmak veya sihirbaz türüne göre belirteçleri döndürmek için bir kaynak oluşturmak veya hatta yalnızca bu belirli tekli doldurmak için yeni bir kaynak oluşturmak gibi bazı şeyleri değiştirmeniz gerekir. adım sihirbazı PUT /users/:id_user/profile/.

— Ricardo Souza
kaynak