Webcím: URL-képzés, Apache document root, keresőbarát URL, HTTP GET és POST metódusok

Az URL (Uniform Resource Locator), mint URI (Uniform Resource Identifier, egységes erőforrás-azonosító) többnyire szinonímája a webcímnek, holott valójában nem csak webcímet jelöl. Tény azonban az, hogy webcímként az ún. namespace-ben (névtér) egyedileg azonosít az egész világhálón egy helyet. 🙂

https://hu.wikipedia.org/wiki/URL

https://hu.wikipedia.org/wiki/URI

URL-ek, a teljesség igénye nélkül:

  1. http://dummy.restapiexample.com/ – ez már kacsintás a REST (Representational State Transfer) témakörbe, egy “sima” HTTP (HyperText Transfer Protocol) webcím, a 80-as porttal kommunikál (így is működik: http://dummy.restapiexample.com:80/)
  2. https://hu.wikipedia.org/wiki/REST – ez egy napjainkra elterjedt biztonságos (HTTPS) webcím (alternatívája a https://hu.wikipedia.org:443/wiki/REST – a portszámot elhagyjuk a gyakorlatban)
  3. ftp://ftp4.de.freesbie.org/pub/linux/metalab/system/emulators/wine – ez egy klasszikus FTP (File Transfer Protocol) cím, szintén kódolatlan, tökéletes file-ok letöltéséhez, és a böngészőnkbe is simán beírható! 🙂 Részletek: https://hu.wikipedia.org/wiki/File_Transfer_Protocol
  4. és akkor a végére egy érdekesség az Internet múltjából – a Gopher -, ilyen is van: http://gopher.quux.org:70/ – natív címen: gopher://gopher.quux.org/1/ – persze ezt már a Chrome böngészőm sem ismeri 🙂

Akkor mostanra kezdjük érteni a cím előtagját és a portszámot. Mit lehet még belefoglalni egy URL-be? Lehet benne pl. felhasználónév és jelszó is! Pl. “ftp://felhasznalonev:jelszo@szervern.ev/konyvtar1/konyvtar2/“. Aztán megnézhetjük a szervernév utáni törtvonal (“/” – perjel) határolta részeket. Ezek egy alap Linux rendszerben az ún. Document root – web gyökér – könyvtárunkban sima könyvtárnevek a filerendszerben. 🙂 Az Apache webszerverünk fordítja át a külvilág felé webes tartalommá. Egy ilyen könyvtárban kérhetjük a szerverünket egy automatikus index oldal megjelenítésére, de az nem túl biztonságos. Általában egy index.php (dinamikus script) vagy index.html (többnyire statikus adat) file kell legyen minden ilyen publikus könyvtárban, hogy az Interneten is megjelenhessen a tartalma. Amit index.html file-ba teszünk azt a sima “/” cím alatt láthatjuk. Tehát ha az Apache Document root-unk “/var/www/html“, a hosztnevünk nextweb.hu, akkor a “/var/www/html/index.html” file az Interneten a böngészőnkben a http://nextweb.hu/ cím alatt látszódik. Megjegyzem, hogy a záró törtvonal a webcím végén nem fontos. 🙂

Szólnunk kell a speciális (pl. magyar ékezetes) karakterek sorsáról URL-ben. Ugyanis nem lehetnek benne igazán az ún. ASCII karaktereken kívül mások. A ” “, space – üres – karaktert pl. “+” jellel vagy “%20”-ként lehet kódolni. Részletesebben az alábbi link alatt olvashatunk erről.

https://www.w3schools.com/tags/ref_urlencode.asp

Fontos lehet a DNS-ről korábban írtak (https://gvamosi.wordpress.com/2019/09/21/ethernet-bridging-switching-routing-es-a-linux-router-tablaja/) figyelembevételével az ún. virtuális hoszting témaköre. Egy feloldott IP-cím “alatt” több szervernév is van a gyakorlatban. Az Apache webszerverrel ezt ún. virtuális szerverek, hosztok (VirtualHost) konfigurálásával és futtatásával oldhatjuk meg. Így lehetséges egy webtárhely szolgáltatónál több webcím regisztrálása és kiszolgálása! Mielőtt azonban ISP-t (Internet Service Provider, azaz Internetszolgáltató) gründolnánk a lakásunkban, elmondanám, hogy azért ahhoz kissé több kell egy PC-nél (cluster-be, fürtbe kapcsolt számítógépek, terhelés-elosztás, azaz load balancing, RAID – redundáns, hibajavító-tűrő módon felépített háttértártömbök, etc.) 🙂

Visszatérve az URL-ekhez. Az URL-ekben, ahogy pl. egy google keresésben láthatjuk, kulcs-érték párokat is “átadhatunk” a szerver oldali programocskánknak (URL-ben lévő paraméterek a GET metódussal jutnak el a szerver oldalra): https://www.google.com/search?q=alma&oq=alma. Itt a “q” értéke “alma”, az “oq” értéke szintén “alma”. Így rákereshetünk a világ legjobb és legnagyobb keresőjében az “alma” kifejezésre. Elég csak a “q”-t megadni, de akkor nem láthattuk volna, hogy a “&” jel a kulcs-érték párok elválasztására való, míg ezeket a “?” választja el az URL első részétől. Na ez a nem keresőbarát. 😀 A google keresőmotorja nem keresőbarát. Persze minek is lenne az! 😀 A keresőbarát jóval közelebb áll a REST megközelítéshez. Világos, könyvtár-szerű, beszédes nevekkel ellátott URL-ek. Pl. ha ID kell bele, akkor nemakarmi.php?id=111“, hanem “/akarmi/111“. A keresők a web feltérképezéséhez ún. robotokat használnak, automatikus programokat – ugyanúgy, akár az ember egy böngészőben, csak egy robot tölti le, és indexeli az oldalt. Amennyiben értelmes kifejezések vannak már magában az URL-ben is, úgy máris eggyel jobb helyen vagyunk a találati listán, mivel a keresők kulcsszónak fogják venni az URL-ben találtakat is! A WordPress rendszerünk szerencsénkre keresőbarát, “beszédesURL-eket használ, ráadásul ún. “permalink“-eket is. Hiszen az is fontos, hogy fél év múlva is megtalálható legyen egy októberi írás, tehát legyen rá egy “permalink“, azaz egy állandó – és beszédeshivatkozás. 🙂

Ide beszúrom – csak az érdekesség kedvéért egy kacsintás az enterprise világába -, hogy a REST HTTP szoftverarchitektúra témaköréhez tartozik a hozzá hasonlóan felépített ún. “RESTful Web services” is. Csupán hogy valamit írhassak a Webszolgáltatásokról (Webservice). 😀

Végül nézzük meg a leggyakoribb HTTP metódusokat, a GET és a POST témákat. A GET-ről írtam a google kereső URL megadásánál. Az nagyjából ennyi. A POST metódussal webes formokat, vagyis ürlapokat küldhetünk el a szervernek, ahol ezek a GET metódussal kapott kulcs-érték párokhoz hasonlóan feldolgozásra kerülnek. Egy file feltöltés pl. tipikusan POST metódussal történik. Bővebben az alábbi linkeken tájékozódhatunk. 🙂

https://hu.wikipedia.org/wiki/HTTP

https://stackoverflow.com/questions/8659808/how-does-http-file-upload-work

Mit értünk webprogramozás, webfejlesztés alatt

A 21. századra rárobbant az információs kor. A World Wide Web, azaz a WWW kora, az Internet multimédia-tartalommal bíró kommunikációs csatornája, a kiszolgáló oldali (web)szerverek – ez volna az Apache vagy az nginx -, és a kliens oldali böngészők – Chrome, Firefox, Edge – kommunikációjaként előálló interakció. Az egész Internet lényegében tekinthető egy online adatfeldolgozó, -tároló és -továbbító rendszernek. Ezért fontos beszélni az adatok tárolására és feldolgozására szolgáló többnyire SQL alapú adatbázis szerverekről is – ezek a MySQL vagy a MariaDB -, illetve a szerver oldali adatfeldolgozó script-ekről, azaz webszerverbe ágyazott szoftverrendszerekről is, melyek sok esetben Perl és PHP nyelveken íródnak. Fontos még említeni a kliens oldal legütősebb script-nyelvét, a JavaScript-et. Legismertebb képviselője a széles körben elterjedt JavaScript könyvtár, a jQuery (https://jquery.com). Az adatok továbbítása valójában a hálózaton keresztül valósul meg, mindig kliens-szerver kommunikációban – lévén ugyanis a szerver egyszerre több klienst is kiszolgál, továbbá a szerverek egymással is tudnak beszélgetni, de adott esetben egy kliens is egyszerre több szerverhez kapcsolódhat. 🙂 Jelen írás a fentiekben leírtak bemutatásával szeretne foglalkozni.

A webfejlesztés tehát minden esetben egy szoftver-rendszerben történik. Egy jó kiindulási szoftver környezet található az alábbi linken.

https://www.apachefriends.org/hu/index.html

Ebben az írásomban szeretném az operációs rendszer, az adatbázis szerver, a webszerver és a kliens oldal összhangját három esettanulmányon keresztül bemutatni. Egyébként a fenti link alatt található XAMPP-ot hívják még LAMP-nak is. Szinte mindegy, hogy melyik variánst vesszük, ugyanaz az eredmény. 🙂 Ez az architektúra (szoftverépítészeti megoldás) igen elterjedt és nagy népszerűségnek örvend, többek között a nem enterprise (nem nagyvállalati vagy nagy volumenű üzleti) felhasználási területen.

https://hu.wikipedia.org/wiki/LAMP_(szoftvercsomag)

Megjegyezném, hogy ezen technológiák ismerete enterprise megoldások kiindulási pontja lehet, illetve hogy nagy dolgokat is meg lehet a segítségükkel valósítani. 🙂

A három esettanulmány – három rész – rendre a következők lesznek:

  1. A nyílt forráskódú, PHP-ban írt WordPress (https://hu.wordpress.org/), weboldalak, blogok és egyéb webes alkalmazások motorjának bemutatása egy webalkalmazáson keresztül.
  2. A nyílt forráskódú CodeIgniter (http://codeigniter.hu/) PHP keretrendszer megismertetése egy webalkalmazáson keresztül. Ez a keretrendszer a letisztult MVC (Model – View – Controller) programtervezési mintát (Design Patterns) követi.
  3. Harmadikként pedig a 30 éve folyamatosan fejlesztett Perl nyelven a szintén nyílt forráskódú Catalyst (http://www.catalystframework.org/, https://www.perl.org/about/whitepapers/perl-webframework.html), nem meglepő módon MVC alapú keretrendszer felhasználásával fogunk webalkalmazást írni. 🙂

Végül lássuk egy szemléltető diagramon az MVC pattern-t. A lényege, hogy mindent a Controller (vezérlő) végez, a modellváltoztatást is, és a felhasználó nézetének változtatását is. 🙂