Vatansız interneti anlama [kapalı]

Masaüstü geliştiricisi olmaktan web geliştiricisine geçiyorum ve HTTP'nin neden vatansız olduğunu anlamakta zorlanıyorum. Bunun nedenleri nelerdir? Benim gibi bir masaüstü geliştiricisinin durumsuz bir geliştirme ortamına geçiş yapmasının bazı yolları nelerdir?

Bu gördüğüm vatansız internetin en iyi açıklaması:

Karıma REST'i Nasıl  Açıkladım
http://www.looah.com/source/view/2284

Karısı: Roy Fielding kim?

Ryan: Bir adam. O akıllı.

Karısı: Ah? Ne yaptı?

Ryan: İlk web sunucularının yazılmasına yardımcı oldu ve ardından web'in neden bu şekilde çalıştığını açıklayan bir ton araştırma yaptı. Adı, sunuculardan tarayıcınıza sayfa almak için kullanılan protokolün spesifikasyonundadır.

Karısı: Nasıl çalışır?

Ryan: Web?

Karısı: Evet.

Ryan: Hımm. Aslında hepsi oldukça şaşırtıcı. Ve komik olan şey, her şeyin çok değerli olması. Bahsettiğim protokol HTTP, insanların bir nedenden dolayı görmezden geldiği her türlü temiz şeyi yapabiliyor.

Karısı: http'yi tarayıcıya yazdıklarımın başlangıcı gibi mi demek istiyorsun?

Ryan: Evet. Bu ilk bölüm tarayıcıya hangi protokolü kullanacağını söyler. Buraya yazdığınız şeyler bilgi işlem tarihindeki en önemli atılımlardan biridir.

Karısı: Neden?

Ryan: Çünkü dünyanın herhangi bir yerindeki bir şeyin yerini dünyanın herhangi bir yerinden tanımlayabiliyor. Web'in temeli budur. Bilgi ve bilgi için GPS koordinatları gibi düşünebilirsiniz.

Karısı: Web sayfaları için mi?

Ryan: Gerçekten her şey için. O adam Roy Fielding, bahsettiğim araştırmada bu şeylerin neye işaret ettiği hakkında çok konuşuyor. Web, REST adında bir mimari tarz üzerine inşa edilmiştir. REST, kaynakların bir tanımını sağlar;

Karısı: Web sayfası bir kaynak mı?

Ryan: Bir çeşit. Web sayfası, bir kaynağın temsilidir. Kaynaklar sadece kavramlardır. URL'ler - tarayıcıya yazdığınız şeyler ...

Karısı: URL'nin ne olduğunu biliyorum ..

Ryan: Ah, doğru. Bunlar tarayıcıya bir yerde bir kavram olduğunu söyler. Bir tarayıcı daha sonra kavramın belirli bir temsilini isteyebilir. Özellikle, tarayıcı kavramın web sayfası temsilini ister.

Karısı: Başka ne tür temsiller var?

Ryan: Aslında, temsiller çok fazla kullanılmayan bu şeylerden biridir. Çoğu durumda, bir kaynağın yalnızca tek bir temsili vardır. Ancak, gelecekte temsillerin daha fazla kullanılacağını umuyoruz, çünkü her yerde bir sürü yeni format var.

Karısı: Ne gibi?

Ryan: Hımm. İnsanların Web Hizmetleri dediği bir kavram var. Bu, birçok farklı insan için birçok farklı şey anlamına gelir, ancak temel kavram, makinelerin web'i tıpkı insanlar gibi kullanabileceği.

Karısı: Bu başka bir robot şey mi?

Ryan: Hayır, pek değil. Makinelerin masada oturacağı ve internette dolaşacağı anlamına gelmez. Ancak bilgisayarlar, iletileri birbirlerine arka arkaya göndermek için aynı protokolleri kullanabilir. Bunu uzun zamandır yapıyoruz, ancak bugün kullandığımız tekniklerin hiçbiri, tüm dünyadaki tüm makinelerle konuşmanız gerektiğinde iyi çalışmıyor.

Karısı: Neden olmasın?

Ryan: Çünkü böyle kullanılmak üzere tasarlanmamışlardı. Fielding ve arkadaşları web'i oluşturmaya başladığında, dünyanın herhangi bir yerindeki herhangi bir makineyle konuşabilmek birincil endişeydi. Bilgisayarların birbirleriyle konuşmasını sağlamak için işte kullandığımız tekniklerin çoğunun bu gereksinimleri yoktu. Sadece küçük bir makine grubuyla konuşman gerekiyordu.

Karısı: Ve şimdi tüm makinelerle konuşman gerekiyor mu?

Ryan: Evet - ve dahası. Diğer makinelerdeki tüm şeyler hakkında tüm makinelerle konuşabilmeliyiz. Bu nedenle, bir makinenin başka bir makineye başka bir makinede olabilecek bir kaynak hakkında bilgi vermesinin bir yoluna ihtiyacımız var.

Karısı: Ne?

Ryan: Diyelim ki kız kardeşinle konuşuyorsun ve süpürgeyi ödünç almak istiyor. Ama sende yok - annende var. Yani kız kardeşine bunun yerine annenden almasını söylersin. Bu gerçek hayatta her zaman olur ve makineler de konuşmaya her zaman olur.

Karısı: Peki makineler birbirlerine şeylerin nerede olduğunu nasıl söyler?

Ryan: Elbette URL. Makinelerin konuşması gereken her şeyin karşılık gelen bir URL'si varsa, bir adın makine eşdeğerini oluşturdunuz. Sen ve ben ve dünyanın geri kalanının isimler hakkında belirli bir şekilde konuşmayı kabul ettiğimiz oldukça önemli, değil mi?

Karısı: Evet.

Ryan: Makinelerin evrensel bir ismi yok - bu yüzden emiyorlar. Her programlama dili, veritabanı veya diğer sistem türlerinin isimler hakkında konuşmanın farklı bir yolu vardır. Bu yüzden URL çok önemlidir. Tüm bu sistemlerin birbirlerinin isimlerini anlatmasına izin verelim.

Karısı: Ama bir web sayfasına bakarken böyle düşünmüyorum.

Ryan: Kimse bilmiyor. Fielding ve bir avuç insan hariç. Bu yüzden makineler hala emiyor.

Karısı: Fiiller, zamirler ve sıfatlar ne olacak?

Ryan: Komik sordun çünkü bu REST'in bir başka büyük yönü. Fiiller zaten.

Karısı: Sadece şaka yapıyordum.

Ryan: Komik bir şakaydı ama aslında hiç şaka değil. Fiiller önemlidir. Programlama ve CS teorisinde polimorfizm adı verilen güçlü bir kavram vardır. Bu, farklı isimlerin kendilerine aynı fiili uygulayabileceğini söylemenin geeky bir yoludur.

Karısı: Anlamıyorum .

Ryan: Şey .. Sehpaya bak. İsimler nelerdir? Kupa, tepsi, gazete, uzak. Şimdi, bunların hepsine yapabileceğiniz bazı şeyler nelerdir?

Karısı: Anlamıyorum ...

Ryan: Onları alabilirsin, değil mi? Onları alabilirsin. Onları devirebilirsin. Onları yakabilirsin. Aynı fiilleri orada oturan nesnelere de uygulayabilirsiniz.

Karısı: Tamam ... öyle mi?

Ryan: Şey, bu önemli. Ya benim yerine, "kupayı al" ve "gazeteyi al" ve "uzaktan kumandayı al" diyebilseydim; bunun yerine isimlerin her biri için farklı fiiller bulmamız gerekiyorsa? Evrensel olarak "get" kelimesini kullanamadım, bunun yerine her fiil / isim kombinasyonu için yeni bir kelime düşünmek zorunda kaldım.

Karısı: Vay canına! Bu tuhaf.

Ryan: Evet, öyle. Beynimiz bir şekilde aynı fiillerin birçok farklı isme uygulanabileceğini bilecek kadar zekidir. Bazı fiiller diğerlerinden daha belirgindir ve sadece küçük bir isim dizisine uygulanır. Mesela bir bardak kullanamam ve araba içemem. Ancak bazı fiiller GET, PUT ve DELETE gibi neredeyse evrenseldir.

Karısı: Bir bardağı SİLEMEZSİNİZ.

Ryan: Tamam, ama atabilirsin. Bu başka bir şakaydı, değil mi?

Karısı: Evet.

Ryan: Her neyse, HTTP - Fielding ve arkadaşları tarafından oluşturulan bu protokol - tamamen isimlere fiil uygulamakla ilgilidir. Örneğin, bir web sayfasına gittiğinizde, tarayıcı girdiğiniz URL üzerinde bir HTTP GET yapar ve geri bir web sayfası gelir.

Web sayfalarında genellikle görüntüler vardır, değil mi? Bunlar ayrı kaynaklar. Web sayfası sadece resimlerin URL'lerini belirtir ve tarayıcı gider ve tüm kaynaklar elde edilinceye ve web sayfası görüntülenene kadar tarayıcıda daha fazla HTTP GET yapar. Ancak burada önemli olan, çok farklı isimlerin aynı şekilde ele alınabilmesidir. İsmin bir resim, metin, video, mp3, slayt gösterisi, her neyse. Bir URL verildiğinde tüm bunları aynı şekilde elde edebilirim.

Karısı: GET gibi geliyor oldukça önemli bir fiildir.

Ryan: Öyle. Özellikle bir web tarayıcısı kullandığınız için tarayıcılar hemen hemen sadece Kaynaklarla başka türlü etkileşimde bulunmazlar. Bu bir sorundur, çünkü birçok kişinin HTTP'nin sadece GETing için olduğunu varsaymasına neden olmuştur. Ancak HTTP aslında fiilleri isimlere uygulamak için genel amaçlı bir protokoldür.

Karısı: Güzel. Ama yine de bunun bir şeyi nasıl değiştirdiğini göremiyorum. Ne tür isimler ve fiiller istiyorsunuz?

Ryan: İsimler orada ama doğru biçimde değil.

Amazon.com sitesine göz atarken beni Noel için satın alacak şeyler mi arıyorsunuz? Her ürünü isimler olarak hayal edin. Şimdi, bir makinenin anlayabileceği bir temsilde mevcut olsaydı, çok düzgün şeyler yapabilirdiniz.

Karısı: Bir makine neden normal bir web sayfasını anlayamıyor?

Ryan: Çünkü web sayfaları insanlar tarafından anlaşılmak üzere tasarlandı. Bir makine, düzen ve stil ile ilgilenmez. Makinelerin temelde verilere ihtiyacı vardır. İdeal olarak, her URL'nin okunabilir ve makine tarafından okunabilir bir temsili olacaktır. Bir makine kaynağı aldığında, makine tarafından okunabilir olanı ister. Bir tarayıcı bir insan için bir kaynak aldığında, okunabilir insanı ister.

Karısı: Yani insanlar tüm sayfaları için makine formatları yapmak zorunda kalacaklardı?

Ryan: Değerli olsaydı.

Bak, bunun hakkında çok soyutlama ile konuşuyorduk. Gerçek bir örnek almaya ne dersin? Bir öğretmensiniz - okulda, öğrencileri yönetmenize izin veren büyük bir bilgisayar sisteminiz veya daha büyük olasılıkla üç veya dört bilgisayar sisteminiz var: hangi sınıflarda olduklarını, hangi notları aldıklarını, acil durum irtibat kişileri, bilgi Öğrettiğiniz kitaplar, vb. hakkında. Sistemler web tabanlıysa, muhtemelen burada yer alan isimlerin her biri için bir URL vardır: öğrenci, öğretmen, sınıf, kitap, oda vb. Şu anda URL'yi almak tarayıcı size bir web sayfası verir. Her URL için makine tarafından okunabilir bir sunum olsaydı, tüm araçların standart bir şekilde tüketilebileceği için yeni araçları sisteme kilitlemek önemsiz olurdu. Ayrıca, her bir sistemin birbirleriyle konuşmasını biraz daha kolaylaştıracaktır. Veya, sınav puanları toplamak için her bir okul sistemiyle her biri ile konuşabilen bir eyalet veya ülke çapında sistem oluşturabilirsiniz. İmkanlar sonsuzdur.

Sistemlerin her biri basit bir HTTP GET kullanarak birbirlerinden bilgi alacaktır. Bir sistemin başka bir sisteme bir şey eklemesi gerekiyorsa, bir HTTP POST kullanır. Bir sistem başka bir sistemdeki bir şeyi güncellemek istiyorsa, bir HTTP PUT kullanır. Çözülmesi gereken tek şey verinin nasıl görünmesi gerektiğidir.

Karısı: Yani siz ve şu anda insanların üzerinde çalıştığı tüm bilgisayar bu mu? Verilerin neye benzemesi gerektiğine karar vermek?

Ryan: Ne yazık ki hayır. Bunun yerine, büyük çoğunluk, bu şeyleri neredeyse faydalı veya etkili olmayan farklı bir şekilde yapmak için karmaşık özelliklerin katmanlarını yazmakla meşgul. İsimler evrensel değildir ve fiiller polimorfik değildir. Onlarca yıllık gerçek saha kullanımı ve kanıtlanmış teknikler atıyoruz ve geçmişte başarısız olan diğer sistemlere çok benzeyen bir şeyle başlıyoruz. HTTP kullanıyoruz, ancak yalnızca ağımız ve güvenlik insanlarımızla daha az konuşmamıza yardımcı olduğu için. Gösterişli araçlar ve sihirbazlar için basit işlem yapıyoruz.

Karısı: Neden?

Ryan: Hiçbir fikrim yok.

Karısı: Neden bir şey söylemiyorsun?

Ryan: Belki yaparım.

Milyarlarca milyarlarca milyarlarca bağlantı durumunu depolamanın nasıl mümkün olacağını düşünüyorsunuz? :) Böylece durumu yalnızca gereken yerlerde oturumlarda saklarsınız.

BTW: HTTP bağlantısız değil.

Masaüstü geliştiricisi olarak zengin kullanıcı arayüzü deneyimleri konusunda daha rahat olabilirsiniz. Web'e geçmek bir adım geri adım atmak gibi hissedebilir. Web dünyasında yaratıcılık özgürlüğü daha azdır ve size bir kısıtlama hissi verebilir. Seni aşağı indirmesine izin verme! Dışarıda geçiş yapmanıza yardımcı olabilecek bir dizi şey var ve bunların kısa bir listesi:

1. Durum paylaşılabilir, ancak sıklıkla sunucuda tutulur ve oturum kimlikleri, URL parametreleri, gizli alanlar veya çerez değerleri gibi belirteçler kullanılarak başvurulabilir.
2. Durum bilgisi olmayan modeller işlem işleme için çok uygundur. Modelinizi, gerekli durum miktarını azaltabilecek şekilde oluşturmaya çalışın. ASİT işlem ilkeleri bunu elde yardımcı olabilir.
3. MVC modelini tanıyın (henüz yapmadıysanız). Bu, endişelerin ayrılmasını sağlayarak tasarımınızı geliştirmenize yardımcı olacaktır. Struts (Java) ve MVC (.NET) gibi bazı popüler çerçeveler bu kavramın etrafında inşa edilmiştir.
4. Süper zengin UI deneyimleri için Java , Flash veya Silverlight gibi bir eklenti kullanmayı düşünün . Yarı zengin deneyimler için JQuery veya AJAX gibi popüler java-script tabanlı kütüphaneleri kullanmayı düşünün .

Mutlu programlama!

Çünkü milyonlarca web sayfasında milyonlarca zamanın olmadığı bir zaman vardı. Çünkü sadece üniversitelerin ve araştırma tesislerinin birkaç sayfası olduğu bir zaman vardı. Geniş bant olmadığı bir zaman vardı ve http masa telefonlarının üzerine yerleştirilmiş 1200 baud modemle iletişim kurdu. "Zengin web uygulamaları" nın, onların görüşüne göre gülünç bir bant genişliği gerektireceği bir zaman vardı. Unutmayın, TCP / IP oluşturuldu çünkü erken internet çok güvenilmezdi.

HTTP 1.0 1990'ların başında geliyordu. O zamanlar internetin nasıl olduğunu ve neden bu şekilde tasarlandığını düşünün.

Her şey evrim geçirdi. İnternet, web tarayıcılarından ve Web'den önce vardı. Ftp, telnet, gopher, ping, parmak ve diğer birkaç bit ve bob'un köpüren bir tenceresiydi. İlk web tarayıcısı Mosaic (? Sanırım, uzun zaman önce, 1991 sanırım, kolejdeydim) ftp ve belge görüntüleyici arasında bir tür karışıklık görevi gördü. Büyü, belgede yeni bir belge oluşturacak bağlantılara sahip olabilmeniz oldu.

Sonraki 20 yıl boyunca geliştirdiğimiz tüm etkileşim. Bu da mutlu bir evrim değildi. Tarayıcı savaşları yaptık, IE ve Netscape bunu standartların kontrolü için indirdi (bir basitleştirme biti;)) ve çeşitli diğer üçüncü taraflar zengin içeriğe izin vermek için eklentileri tanıtmaya başladı. Java sihirli kurşun ve elbette Flash olacaktı. 3D dünyalar vaat eden ve Star Wars modellerinin tam olarak yarım düzine 3d modelini sunan VRML eklentilerini hatırlayan var mı?

Sonuna doğru biraz uzaklaştım, ama fikri anladın :)

Birincil nedenler, asedeminin HTTP'nin amacına inandığı şeyin ve ölçeklenebilirlik nedenlerinin bir kombinasyonu ile ilgilidir. HTML başlangıçta akademik sınırlar boyunca bilgi veya tez paylaşmak için tasarlanmıştır. Tamamen stilize edilmiş bir metindi. İlk tarayıcı, insanların bu modelin ötesinde düşünmeye başladığı resimleri sunmanıza izin verene kadar değildi.

Aşağıdaki hususlar vatansız kararı sağlamlaştırdı:

• Tipik etkileşim hızlı bir indirme ve okuma olacaktı. Bir sonraki talebe kadar olan gecikme sırasında soket boşta kalırdı.
• Soketler değerli sistem kaynaklarını kullanır. SMTP ile yaptığınız gibi bir görüşme yapmak zorunda kalmazsak, bir makinenin binlerce istemciyi ele alması için çok şey yapabilirsiniz.
• Uzak kabuk hesaplarını, NFS, SMTP ve diğer durumsal bağlantı protokollerini yöneterek değerli dersler öğrendiler.

Web sayfaları daha karmaşık hale geldikçe ve çok sayıda grafik ve stil sayfası içerdikçe, HTTP "canlı" bayrağıyla değiştirildi. Bu, soketi canlı tutar ve istemcinin aynı konuşma ile birkaç kaynak istemesine izin verir.

İnternetin mevcut kullanım modeli göz önüne alındığında, orijinal karar hala geçerlidir. Zaman zaman rahatsız edici olabilir, ancak bir sunucu ile birkaç küçük, nicel etkileşim, boş yuvalardan daha iyi ölçeklenir.

İki yönlü tarayıcıları kastediyorsanız.

Güvenlik nedenleri.

Örneğin SPAM !.

Web'de Çift Yönlü İletişimi Bir Sonraki Düzeye Taşıyor

Aksi takdirde internet TCP / IP (iki protokol) ve UDP çalıştırır.

İletim Kontrol Protokolü(TCP), Internet Protokolü Paketi'nin temel protokollerinden biridir. TCP, Internet Protokolü'nü (IP) tamamlayan paketin iki orijinal bileşeninden biridir ve bu nedenle paketin tamamı genellikle TCP / IP olarak adlandırılır. TCP, aynı ağdaki iki ana bilgisayar arasında doğrudan veri alışverişi hizmeti sağlarken IP, adresleme ve yönlendirme mesajını bir veya daha fazla ağ üzerinden işler. Özellikle, TCP, bir bilgisayardaki bir programdan başka bir bilgisayardaki başka bir programa bayt akışının güvenilir ve düzenli bir şekilde gönderilmesini sağlar. TCP, Internet uygulamalarının güvendiği, World Wide Web, e-posta ve dosya aktarımı gibi uygulamalardır. Güvenilir veri akışı hizmeti gerektirmeyen diğer uygulamalar,

İnternet Protokolü(IP), Internet Protokol Paketi'ni kullanarak bir ağ üzerinde datagramları (paketleri) aktarmak için kullanılan temel iletişim protokolüdür. Paketlerin ağ sınırları boyunca yönlendirilmesinden sorumlu olan, interneti kuran birincil protokoldür. IP, Internet Protokolü Paketi'nin Internet Katmanı'ndaki birincil protokoldür ve veri adreslerini yalnızca adreslerine göre kaynak ana bilgisayardan hedef ana bilgisayara teslim etme görevine sahiptir. Bu amaçla IP, datagram kapsülleme için adresleme yöntemlerini ve yapılarını tanımlar. Tarihsel olarak IP, 1974'te Vint Cerf ve Bob Kahn tarafından sunulan orijinal İletim Kontrol Programında bağlantısız datagram hizmetiydi; diğeri bağlantıya yönelik İletim Kontrol Protokolü (TCP) idi. Bu nedenle, Internet Protokol Paketi'ne genellikle TCP / IP denir.

Bir masaüstü uygulamasında, kullanıcının tanımlı bir başlangıç ​​ve bitiş ile bazı görevleri gerçekleştirdiği varsayılır. Böyle bir uygulamada, kullanıcıların verilerini sağlayan herhangi bir sunucuya giriş yapmaları ve tamamlanıncaya kadar giriş yapmış olmaları mantıklıdır (aslında çok değil).

Web etkileşimleri (genellikle) aynı modeli izlemez. Örneğin, bir e-Ticaret sitesinde, kullanıcı bir Google aramasının sonucu olarak ürün açıklamasına ulaşabilir ve başka bir sitenin aynı ürünün teklifine bakmak için o sayfayı hemen bırakabilir. Veya ödeme sürecini başlatabilir, ardından ürünün çok pahalı olduğuna karar verebilir ve yarıya kadar terk edebilir. Temel "hipermetin" fikri, bir yerden başka bir yere atlama yeteneğini ve beklentisini ifade eder.

Kalıcı bağlantılar kaynakları tüketir. Belki sadece bir ağ soketi, belki de ayrıştırılmış veritabanı sorguları havuzu; her şey uygulamaya bağlıdır. Herhangi bir zamanda kaybolabilecek bir kullanıcı göz önüne alındığında, bu kaynakların kararlı tutulması pek mantıklı değildir.

Uygulamada, kullanıcının kalıcı bir bağlantıya sahip olmasına gerek yoktur. Web uygulaması, ihtiyaç duyduğu kaynaklara (ör. Veritabanı) bağlantı sağlar ve bunları tüm kullanıcı istekleri arasında paylaşır. Web uygulaması çerçevesi, farklı istekler için kullanıcı başına verileri depolamak için zaman sınırlı yerler olan oturumlar sağlar. (Kolayca) yapamayacağınız tek şey, uzun süredir müşteri tarafından kontrol edilen işlemlere sahip olmaktır, ancak bu, bağlantıları sürdüren bir uygulamada bile kötü bir fikirdir.

İnternet mutlaka vatansız değildir - aslında Java EE'ye baktığınızda - Durumsal EJB'lere ve Vatansız EJB'lere sahiptir.

Geliştiricilerin durumsuz bir mimari kullanılmasını önermelerinin ana nedeni ölçeklenebilirliktir. Trafiğinizi desteklemek için sunucu ekleyip bıraktığınızda, tüm kullanıcılarınızın durumunu korumaya çalıştığınızı düşünün.

Vatansız bir mimari geliştirmek gerçekten zor değil. Ana nokta, mümkün olduğunca az durumu (genellikle bir kullanıcı kimliği - tercihen bir çerezde) tutmak ve veritabanını gerektiği gibi değiştirmek.

Bence bu şekilde başladı ve böyle olmaya devam etti. Etrafında çok fazla altyapı inşa edildiğine göre, onu değiştirmek imkansız.

Belki de vatansız başladı çünkü bağlantılar başlangıçta daha az güvenilirdi ve bant genişliği daha küçüktü. Çok fazla etkin bağlantınız yoksa, daha fazla trafiği daha kolay yönetebilirsiniz.

Daha iyi bilginiz varsa ya da daha iyisi kendi cevabınızı gönderin lütfen düzenleyin ya da yorum bırakın!

Çünkü sunucular bir hizmet sağlar (onun adına). Bir istekte bulunuyorsunuz ve cevaplar alıyorsunuz - hepsi bu kadar.

Web geliştirmeye geçiş yapmakla ilgili olarak, ASP.NET Web Formlarının sizin için daha anlaşılabilir bir şekilde yapacağına inanıyorum - ama bu sadece soyutlama katmanları altında neler olduğunu gizlediği için.

HTTP (Köprü Metni Aktarım Protokolü) adı analiz edilerek çok şey anlaşılabilir. Hiçbir zaman zengin bir UI protokolü olarak tasarlanmamıştır. Asıl fikir, aralarındaki bağlantılarla belgeleri paylaşmaktı. Senden bir belge istiyorum, o belgenin bir kopyasıyla cevap veriyorsunuz.

Başlangıçta HTTP'nin sadece bir fiili GET vardı. Bu bağlamda, statik içerik için tasarlanmıştır. Yaptığınız tek şey birinin paylaştığı bir belge isterken neden bir duruma ihtiyacınız var? Bu yüzden HTTP kökensiz ... vatansız.