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:
- 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/)
- 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)
- 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
- é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 nem “akarmi.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édes” URL-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édes – hivatkozá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
Apache, MySQL/MariaDB, Perl/PHP 