Bu “anti-desen” mi ve kullanmayı bırakmalı mıyım yoksa bu akıllı tasarım mı?

Temelde bir REST hizmeti oluştururken aşağıdakileri yapmaya baktım:

1. HTML isteniyor
2. hizmet istenen web sayfasını döndürür ancak istenen "kaynak" olmadan, ör. veri
3. web sayfası aynı hizmete AJAX isteği gönderen JavaScript içeriyor (farklı içerik türü)
4. hizmeti daha sonra gerçek verileri (JSON) döndürür ve sayfa verileri görüntüler

Bir tarafta verimsiz görünüyor (2 istek), ancak daha sonra bunu kullandım, "performans kaygısız", yani düşük trafikli dahili uygulama ve web siteleri basit ve hızlı yük.

Bununla sonuçlanan nedeni, web sayfasının neredeyse saf Html + JavaScript olabileceği ve bunun gibi tablolar ve şeyler oluşturmak için neredeyse hiç sunucu tarafı malzeme gerekmiyor, özellikle döngüler yok (ki bu çok çirkin olduğunu düşünüyorum) slickgrid gibi şeyler), örneğin verilerin ayrılması ve görünüm.

Bunu kullanmaya başlamadan önce, bu iyi bir fikir mi yoksa sadece yapmayı bırakmalı mıyım?

Bir kaynak talep ederseniz ve veri içermiyorsa, REST hizmeti değil. Json'da gerçek verileri sağlayan servis olabilir, ancak HTML kısmı değildir. Bir web uygulaması için önemli değil.

Teknik çalışır, ancak sınırlamalarının farkında olmanız gerekir:

1. Arama motorları JavaScript'i yorumlamaz, bu nedenle bu şekilde uygulanan site Google ve benzerleri tarafından dizine eklenemez. Dahili uygulama için önemli değil, halkın karşı karşıya gelmesi için çok önemlidir.
2. Özel ihtiyaçları olan kullanıcılar (Braille terminalleri kullananlar gibi) oldukça sınırlı olan ve JavaScript'i düzgün yorumlayamayacak özel tarayıcılar kullanır.

Ayrıca HTML üreten kodun sunucu tarafında mı yoksa istemci tarafında mı çalıştığı temelde aynıdır. Sunucu tarafında hem dil hem de çerçeve seçenekleri çok daha büyük ve eminim slickgrid birkaç eşdeğer olduğundan eminim.

Sunucu tarafında veri ve görüntü ayrımı yapmaya devam edebilir ve devam ettirebilirsiniz. Şablon sistemi, verileri veri yapısı veya hatta json (özellikle de gerçek hizmet, şablon sisteminden farklı bir dilde ise) olarak alabilir ve almalıdır ve bu verileri içeren bir şablonu genişletebilir.

Ve hayır, PHP hakkında düşünmüyorum; orada en az yetenekli şablon sistemidir (bunun üzerine inşa edilmiş daha iyi olanlar da vardır). Genshi veya XSLT veya web widget'ları sağlayan daha gelişmiş bir şey düşünüyorum .

Kodunuzu temiz bir şekilde yapılandırdığınızdan emin olduğunuz sürece, bununla ilgili yanlış bir şey yoktur. Statik içeriği web hizmetiniz yerine bir Apache'den bile sunabilirsiniz.

Bu iyi bir uygulamadır. Ve her zaman yapılır, @JanHudec'in belirttiği gibi althogugh, bir REST hizmeti olarak adlandırmak yanlıştır. Ancak birçok web sitesi bunu tam olarak belirttiğiniz nedenlerle yapıyor.

Buna bir anti-desen demezdim, tarif ettiğiniz şey , Trello gibi hizmetlerin aksine, az ya da çok şişman bir müşteri . Sunucunun ilk sorumluluğu DOM'yi ve istemcinin çalışması için gereken kaynakları göndermektir. Veri merkezi otomasyonu ve ağ izleme alanlarında benzer projeler üzerinde çalıştım.

İstemci seyrek bir DOM olarak başlar, bazı verileri XHR aracılığıyla (bazen JSONP aracılığıyla) çeker ve sonunda kendisini bir soket sunucusuna bağlar. Daha da temel bir örnek, bir sohbet uygulaması olacaktır.

Tek nedeni değil bunu yapmak için doğru almak için son derece zor olabilir olmasıdır. Eşzamansız fonksiyonel programlamadan ve karşılaşabileceği tüm yarışlardan ve diğer zorluklardan memnunsanız, bunu korumakta sorun yaşamazsınız. Daha da önemlisi, yazarken sorun yaşamayacaksınız, böylece diğer insanlar sonunda bakımını yapabilirler.

Daha fazla özellik ekleme düşüncesi sizi korkutmaya başlarsa veya hata ayıklamanın bir kabus olduğunu bulmaya başlarsanız, denemeye ve öğrenmeye devam ederken üretimdeki diğer yöntemleri de düşünebilirsiniz.

Kendiniz için bir delik kazmadığınız sürece geçerli bir tasarımdır. Temiz bir arayüz yerine her yerde rastgele JS gobs ve gobs varsa, muhtemelen yeniden faktör veya proje farklı gitmek istiyorum. Tüm kaynaklar yüklendikten sonra çalıştırılacak şekilde tanımlanan işlevlerin çoğu anonim olmalı ve temiz bir arayüzden girilmelidir. Eğer değillerse, belaya gidebilirsiniz.

@Jan Hudec'in dediği gibi, yaklaşımınız kesinlikle REST olarak adlandırılamaz. Gerçi istemci bir kaynak için istediği kısım olabilir. İstemcinin sunum bölümünü ele alması daha iyidir backbone. Kaynaklar için REST sunucusuyla iletişim kurar ve bunları kullanarak görüntüler views.

Bu bir anti-desen olabilir, ama aynı zamanda web uygulamalarının geleceği olduğunu düşünüyorum. Bununla birlikte, JavaScript ile uğraşmak yerine, en azından bir şablon kütüphanesi kullanmalısınız. Daha iyi bir çözüm AngularJS gibi bir istemci tarafı MVC çerçevesidir (ki şimdi kullanıyorum).

Bazı referanslar için, birkaç çerçeveyi karşılaştıran popüler bir blog yazısı ve aynı programı birden çok çerçeve kullanarak uygulayan bir site .

Ayrıca: Jan Hudec'in arama motoru etkileşimi ve ekran okuyucuları hakkındaki yorumları geçerlidir. Bir e-Ticaret sitesinde (pagerank önemli olan) çalışıyorsanız, muhtemelen istemci tarafı çerçeveleri kullanmak istemezsiniz. Ancak dahili uygulamalar için bunlar genellikle endişe verici değildir.

Yaptığınız iş kulağa hoş geliyor! Ancak json yanıtlarınız herhangi bir HTML içeriyorsa, zamanınızı boşa harcarsınız.

Başka bir nokta da aptal müşterinizin json verilerini muhtemelen farklı bir projeden alması gerektiğidir. Müşteri ve hizmet arasında doğru bir ayrım yapmayı hedeflemelisiniz, o zaman uygun bir RESTful hizmetiniz olacaktır