API ve ön uç arka uç arasındaki fark

"Standart" bir işletme web sitesi yazmaya çalışıyorum. "Standart" derken, bu site ön uç için olağan HTML5, CSS ve Javascript, bir arka uç (bir şeyler işlemek için) çalıştırır ve veritabanı için MySQL çalıştırır. Bu temel bir CRUD sitesidir: ön uç veritabanının deposunda ne varsa yapar; arka uç kullanıcı ne girerse veritabanına yazar ve biraz işlem yapar. Tıpkı çoğu site gibi.

Kodlamaya başlamak için Github veri havuzlarımı oluştururken, ön uç arka uç ve API arasındaki farkı anlamadığımı fark ettim . Sorumu ifade etmenin başka bir yolu: API bu resme nereden geliyor?

Daha fazla ayrıntı ve daha sonra sorularım listeleyeceğim - umarım bu size gerçek sorumun ne olduğu hakkında daha iyi bir fikir verir, çünkü soracağım kadar karışıkım ki soracağım soruyu bilmiyorum.

Bazı ayrıntılar:

• Model-View-Controller modelini denemek istiyorum. Bunun soru / cevabı değiştirip değiştirmediğini bilmiyorum.
• API RESTful olacak
• Ben istiyorum benim kendi API kullanmak için arka uç hile ve özel sorguları çağırmak için arka uç izin vermek yerine. Bu tarzın daha tutarlı olduğunu düşünüyorum.

Sorularım:

• Ön uç, API'yi çağıran arka ucu çağırıyor mu? Yoksa ön uç, arka ucu aramak yerine API'yi mi çağırıyor?
• Arka uç sadece bir API yürütüyor mu ve API arka uca kontrol döndürüyor mu (arka uç nihai temsilci görevi görüyorsa, görevleri devrediyorsa)?

Ön uç arka ucunun yanında API'nın rolünü açıklayan uzun ve ayrıntılı yanıtlar teşvik edilir. Yanıt, programlama modeline (Model-Görünüm-Denetleyici modeli dışındaki modeller) bağlıysa, lütfen bu API'yı düşünmenin diğer yollarını açıklayın. Teşekkürler. Kafam çok karışık.

Sanırım API terimi birçok web geliştiricisi tarafından yanlış ve kötüye kullanım biçimiyle karıştırılıyor.

• API, Uygulama Programlama Arayüzü, yani farklı sistemler (veya aynı sistemin parçaları) arasında resmi olarak belirlenmiş herhangi bir arabirim anlamına gelir.
• Bir süre önce, tipik olarak REST ve JSON kullanan bir web hizmeti API'sı aracılığıyla dahili verilerinin bir kısmına halka erişim sunmak, böylece üçüncü taraf geliştiricilerin sistemleriyle entegre olmasını sağlamak, web başlangıcı için büyük bir şey haline geldi. Web geliştiricileri, "genel olarak erişilebilir" web hizmeti "anlamına gelmek için" API "terimini kullanmaya ve bunların uygulanmasını içerecek şekilde kötüye kullanmaya başladı.
• Son kullanıcı ve arka uç açısından, bu web hizmeti API'si (ve uygulaması) olduğu arka uç . Bazı bölümleri kamuya açıkken, bazıları yalnızca kullanıcı arabiriminize erişilebilir.
• Bunun için farklı bir ad "hizmet katmanı" dır, yani
  • ön ucun çağırdığı hizmetleri temsil eder
  • hiçbir görüntü mantığı içermez (sonuçta ön ucun işi budur)
  • basit CRUD eylemlerinden daha soyut ve kaba tanelidir (bir servis çağrısı genellikle birden fazla CRUD eylemi içerir ve bir veritabanı işlemi içinde yürütülmelidir).
  • uygulamanın iş mantığını içerir

Hem "ön uç" hem de "arka uç" ile "tipik" bir web sitesinin mimarisini çizelim. Ve bu bir web sitesi olduğundan, biz de bir "müşteri" var. (Bir tarayıcıda JavaScript'in doğrudan bir sunucuda MySQL'i çağırmasının bir yolu olmadığından.)

Anlaşılır olması için kullandığımız terimler:

• İstemci : HTML5 uyumlu tarayıcı, esp. DOM ve oradaki JavaScript'i değiştirmek için yükledi.
• Ön Uç : DOM'un işaret ettiği PHP sunucusu, hem istenen sayfayı hem de bazı AJAX tarzı XML veya JSON erişim noktalarını içerir.
• Arka uç : MySQL'in çalıştığı bir veritabanı sunucusu.

Düzgün tasarlanmış bir program için, bu bileşenlerin her birinin diğerleriyle iletişim kurmak için özel bir API'si vardır. "Ön uç" PHP kodu SELECTdoğrudan rastgele SQL deyimleri yayınlamaz , bunun yerine arka uç sunucuda çalışan tamamen farklı bir PHP örneğine depolanmış yordamları, önceden yetkilendirilmiş SQL'i veya hatta farklı PHP çağrılarını çağırır . Bu saklı yordamlar veya farklı HTTP çağrılarının kendisi bir API'dir.

Tasarımımızın bir miktar safsızlığına izin versek bile tanım değişmez. Senin Eğer PHPdosya yazıyor ve MySQL doğrudan SQL dizesi gönderir BT HALA BİR API IS tekrarlamayı teşkil etmeyeceğini çok sıradışı bir de olsa.

Herhangi bir AJAX voodoo olmadan, ön uç php kesinlikle senkronize olması tamamen mümkün olduğunu unutmayın. Söz konusu eşzamanlı dosyada aynı harici PHP işlevlerini çağırırsanız, burada "API" teriminin kullanımı gerçek bir netlik vermese de, istemci tarafı sürümüyle aynı API'yi kullandıklarını düşünebilirsiniz.

Sonuçta, bir Uygulama Programlama Arayüzü olarak bir API ve bir programın kendi işlemi dışında herhangi bir çağrıyı gerçekten ifade eder . Hem ön ucu hem de arka ucu olan bir proje yazıyorsanız, yukarıdaki gibi AJAX / PHP / MySQL veya MS Access / SQL Server olun, birbirinizi nasıl arayacağınız konusunda açıklık belirtmek faydalı olacaktır, eğer bir şey kırıldığında nereye bakacağınızı bilmekten başka bir sebep yoksa.

(Ve genel API konusu tamamen başka bir şeydir. Yukarıdaki örneğimizde, yalnızca istemcide görüntülenen URL "genel API" dır. Diğer her şey, özünde "özel" dir. dahili API'nızı çağırmak için kontrolünüz dışındaki herhangi bir kodu kullanırsanız ve bu tür sonuçları açıkça reddedersiniz veya gelecekte bunu yapma hakkını saklı tutarsınız.

API, json, xml vb. gibi belirli bir formattaki verileri almak için jeton erişiminize bağlı olarak kullanılabilen GET, POST, FETCH, DELETE ... gibi http isteklerini işler.

Bu "veriler", bazı kitlelerin ilgisini çekebilecek verileri toplamak için halka açık bir web hizmeti olan API (Uygulama Programlama Arayüzü) almak için kendi uygulamanızda kullanılabilir.

Bu veriler, başarısız olduğunu gösteren bir veri kümesi döndürebilir veya API sunucusundan veri alabilir

API'nın arka uç olması amaçlanmıştır, böylece herhangi bir ön uç ortamında kullanılabilir. Bu, https isteklerini işleyebilen bir web, android, ios ... uygulamasında kullanılabileceği anlamına gelir