BABE ¸ S -BOLYAI UNIVERSITY CLUJ–NAPOCA FACULTY OF MATHEMATICS AND INFORMATICS SPECIALIZATION : COMPUTER SCIENCE License Thesis RESTful Web Services… [602814]

BABE ¸ S -BOLYAI UNIVERSITY CLUJ–NAPOCA
FACULTY OF MATHEMATICS AND INFORMATICS
SPECIALIZATION : COMPUTER SCIENCE
License Thesis
RESTful Web Services – Web
application development with JAX-RS
Abstract
Nowadays the web technologies are very popular, from these I want to mention the REST, which is
becoming increasingly widespread. In this thesis, I would like to present the RESTful web services, as
well as an application based on this technology. We illustrate in more detail the implementation, building
on the theoretical introduction of the thesis.
Presenting the application, I want to demonstrate some opportunities that can be exploited using
REST. The communication between the client and the server side gets an important role here. The app-
lication serves at the same time the popularization of music. Using this application, people have the
possibility to register, after this step they have access to the services provided. They have the opportunity
to upload sheet music as a pdf, to attach sound recordings, as well as associated information, other users
can visualize, add it to the list of favorites, play sound files, or write comments on it.
Today’s applications have to meet many requirements, which is often difficult to fulfill. The REST
API can help us by lending the following properties to the application: scalability, good performance,
simplicity, transparency, portability, reliability.
This work is the result of my own activity. I have neither given nor received unauthorized assistance
on this work.
JULY 2016 B ALLA TAMÁS
ADVISOR :
LECT. PROF.DR. RUFFLAURA

BABE ¸ S -BOLYAI UNIVERSITY CLUJ–NAPOCA
FACULTY OF MATHEMATICS AND INFORMATICS
SPECIALIZATION : COMPUTER SCIENCE
License Thesis
RESTful Web Services – Web
application development with
JAX-RS
SCIENTIFIC SUPERVISOR :
LECT. PROF.DR. RUFFLAURASTUDENT: [anonimizat]ÁS
JULY 2016

UNIVERSITATEA BABE ¸ S -BOLYAI , CLUJ–NAPOCA
FACULTATEA DE MATEMATIC ˘A ¸ SI INFORMATIC ˘A
SPECIALIZAREA INFORMATIC ˘A
Lucrare de licent ¸ ˘a
Servicii web de tip REST –
Dezvoltarea unor aplicat ¸ii web cu
JAX-RS
CONDUC ˘ATOR ¸ STIIN ¸ TIFIC :
LECTOR DR . RUFFLAURAABSOLVENT: [anonimizat]ÁS
IULIE 2016

BABE ¸ S -BOLYAI TUDOMÁNYEGYETEM KOLOZSVÁR
MATEMATIKA ÉS INFORMATIKA KAR
INFORMATIKA SZAK
´Allamvizsga-dolgozat
REST t´ ıpus ´ u webszolg ´altat ´asok –
Webalkalmaz ´asok fejleszt ´ese
JAX-RS seg´ ıts ´eg´evel
TÉMAVEZET ˝O:
DR. RUFFLAURA ,
EGYETEMI ADJUNKTUSSZERZ ˝O:
BALLA TAMÁS
2016 J ÚLIUS

Tartalomjegyz ´ek
1. Bevezet ˝o 4
2. Alapok 6
2.1. REST alapjai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. URI használata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Er ˝oforrások elérése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Hasonl ´o technol ´ogi´ak 9
4. A REST ´altal ´anos m ˝ uk ¨od´ese 11
4.1. REST – Szerver oldali általános feladatok . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. REST felhasználása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. REST szolgáltatások elérése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. REST-et t ´amogat ´o elterjedt szoftvereszk ¨oz¨ok 14
5.1. Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. RESTful keretrendszerek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.2. JAX-RS Jersey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. RESTful architekt ´ ur ´aval k ´esz´ ıtett alkalmaz ´as 17
6.1. Ismertetés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2. Funkcionalitások . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Alkalmaz ´as elk ´esz´ ıt ´es´ehez felhaszn ´alt technol ´ogi´ak 19
7.1. Szerver oldal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1.1. Szolgáltatások elérése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1.2. Adatok tárolása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.2. Üzenet típusok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.3. Kliens oldal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.3.1. AngularJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8. Alkalmaz ´as architekt ´ ura 25
8.1. Adatbázis hozzáférés megvalósítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.2. Alkalmazás használati esetei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9. Alkalmaz ´as megval ´os´ ıt´asa 28
9.1. Jersey szolgáltatások használata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. Az alkalmazás keretén belül elérhet ˝o REST szolgáltatások . . . . . . . . . . . . . . . . 28
9.3. Válasz objektumok el ˝oállítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.4. Szolgáltatás igénybevétele felhasználói oldalról . . . . . . . . . . . . . . . . . . . . . . 30
9.5. Fejlesztéshez használt eszközök . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.6. Válasz feldolgozása kliens oldalon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2

TARTALOMJEGYZÉK
9.7. Kihívások/érdekességek a fejlesztés során . . . . . . . . . . . . . . . . . . . . . . . . . 33
10. Felhaszn ´al´oi dokument ´aci´o 34
10.1. Alkalmazás üzembe helyezése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.2. Alkalmazás használata/esettanulmányok . . . . . . . . . . . . . . . . . . . . . . . . . . 34
11. K ¨ovetkeztet ´esek 38
11.1. Továbbfejlesztési lehet ˝oségek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3

1. fejezet
Bevezet ˝o
A mai informatikai rendszerek igen nagy mennyiség˝ u adattal kell dolgozzanak ezeket továbbítaniuk
kell, amelyek nagy része hálózaton keresztül történik, megfelel ˝o tervezés nélkül szinte lehetetlenné válik
egy id ˝o után a rendszerek karbantartása, mivel annyira összetettek lesznek. Ennek a problémának az
orvoslására volt kialakítva a REST típusú architektúra amely nagy rendszerek esetében is megállja a
helyét. Megalapítója Roy Fideling, aki 2000-ben a doktori disszertációjában vezette be, Roy egyike volt
a HTTP [18] protokoll szerkeszt ˝oinek is. Ez is késztethette egy olyan architektúra kifejlesztésére amely
a HTTP analógiáján alapszik.[13]
A REST típusú (RESTful) architektúra lényege, hogy hálózati kommunikáció megvalósítására
próbál útmutatást adni, a kommunikációban részt vesznek kliensek és szerverek. A szerverek adatokat
tárolnak, amelyek hálózaton keresztül elérhet ˝oek, ha a kliens információkat szeretne szerezni, kérést
küld a megfelel ˝o szerverhez, amely a megfelel ˝o választ generálva visszaküldi azt. A REST architektúra
ezt a folyamatot specifikálja, amelynek f ˝o alkotó elemei az er ˝oforrás azonosítók (URI), er ˝oforrások és
azok reprezentációi. A REST(Representational State Transfer) rövidítés is ezeket az elemeket jelöli. Az
er˝oforrások lehetnek adatok, szolgáltatások amelyeket elérhet ˝ové tehetünk a kliensek számára. Minden
er˝oforrás egyedi azonosítóval kell rendelkezzen amelyeket ismerve, a kliensek által elérhet ˝oek lesznek.
Egy er ˝oforrás reprezentáció valójában egy dokumentum amely az adatok, szolgáltatások aktuális
állapotát rögzíti, ezek elérése üzenet alapú kommunikáción keresztül történik. Az üzenetek önleíró
típusúak ezek leggyakoribb formája HTML, XML, JSON[4] ezeket a szerver megfelel ˝oen kódolja és a
kommunikációs csatornán válaszként visszaküldi a kliensnek.
Azért választottuk a REST technológiákat, mert egyre elterjedtebb, már széles körben alkalmazzák,
a régebbi rendszerek is próbálnak áttérni, az újakat pedig nagy részben már ezzel tervezik, segítségé-
vel jól átlátható, skálázható, lazán csatolt, hordozható rendszerek fejleszthet ˝oek. A dolgozatunk célja,
hogy bemutassa a RESTful webes szolgáltatásokat, m˝ uködésüket, el ˝onyeit és hátrányait valamint össze-
hasonlítani más hasonló technológiákkal. Ugyanakkor szeretnénk egy ezzel a technológiával általunk
készített alkalmazást bemutatni, megemlítjük, hogy milyen tervezési lépésekre kell figyelni és elvégezni.
Az alkalmazás zenei téren használatos, mivel szeretek zenélni és érdekel a zene azért választottuk ezt az
ágazatot, ezzel együtt az alkalmazás a zene népszer˝ usítését is szolgálja.
Áttekintés: Az 1. fejezetben áttekintjük, hogy miért is fontos egy ilyen architektúra, használata, illet-
ve, hogy miért választottuk ezt a témát a dolgozat elkészítésére. A 2. fejezet ismerteti, hogy mi is az a
4

1.FEJEZET : B EVEZET ˝O
REST, honnan indult, melyek az alapjai, miket szükséges ismernünk ahhoz, hogy használni tudjuk. A 3.
fejezetben hasonló technológiákat hasonlítunk össze, illetve megvizsgálunk néhány el ˝onyt és hátrányt.
A 4. fejezetben bemutatjuk általánosan a REST m˝ uködését, valamint, hogy mikor érdemes használni és
mikor nem, illetve, hogyan érhetünk el REST szolgáltatásokat. Az 5. fejezetben megnézünk néhány szoft-
vereszközt, amelyek segítségével RESTful alkalmazást készíthetünk és b ˝ovebben bemutatjuk a Jersey-t
amellyel az általunk fejlesztett alkalmazás is készült. A 6. fejezetben bemutatjuk, hogy az általunk ké-
szített alkalmazás milyen célt szolgál, illetve, milyen funkcionalitásokkal rendelkezik. A 7. fejezetben
az alkalmazás elkészítéséhez használt technológiákat mutatjuk be, kliens illetve szerver oldalon. A 8. fe-
jezetben az alkalmazás architektúra bemutatását találjuk, ahol részletezzük, az adatbázis hozzáféréshez
felhasznált mintát, illetve az alkalmazás használati eseteit. A 9. fejezetben az alkalmazás konkrét meg-
valósítását mutatjuk be, hogyan használjuk a REST szolgáltatásokat, hogyan kommunikálunk a kliens
oldallal, illetve megnézünk egy szolgáltatás igénybevételének folyamatát. Bemutatjuk a fejlesztéshez
felhasznált eszközöket is. Megemlítünk néhány kihívást amelyekkel a fejlesztés során találkoztunk. A
10. fejezetben a felhasználói dokumentációt találjuk, ahol bemutatjuk, miként lehet üzembe helyezni
az alkalmazást, ezek után megnézünk néhány esettanulmányt, hogy miként lehet az alkalmazást rendel-
tetésszer˝ uen használni. A 11. fejezetben következtetéseket vonunk le a fejlesztés folyamatáról, illetve
ajánlunk az alkalmazásra nézve néhány továbbfejlesztési lehet ˝oséget.
5

2. fejezet
Alapok
2.1. REST alapjai
A REST architektúra Roy Fielding megszorításai [12] alapján a következ ˝o feltételeknek kell eleget te-
gyen, ha ezek teljesülnek akkor RESTful-nak nevezhetjük a rendszert.1
Egységes interfész
A kliens és szerver egységes interfészen keresztül kommunikál, ez nagy mértékben leegyszer˝ usíti az
architektúrát és elkülöníti egymástól a részeket, így lehet ˝oség van egymástól függetlenül fejleszteni a
részeket. Az interfész alapú tervezés elvei, a következ ˝oket kell biztosítsák
–er˝oforrások azonosítása URI segítségével történik
–a válaszok önleíró adattípusokban vannak reprezentálva, amelyek tartalmazzák a feldolgozáshoz
szükséges adatokat is
–er˝oforrások módosítása reprezentációkon keresztül történik (XML, JSON, metaadatok, stb.)
Állapotmentesség
A szerver nem tárolja a kliens állapotát a kérések között, minden egyes kérésnek tartalmaznia kell az
összes információt a különböz ˝o állapotok között.
Gyorsítótárazhatóság
A gyorsítótár nagy mértékben felgyorsíthatja az alkalmazást, viszont meg kell oldani azt a problémát,
hogy a kliens elavult adatokat használjon, ezért az üzenetekben szerepelnie kell, hogy elmenthet ˝o-e az
adott üzenet gyorsítótárba vagy sem.
1.Roy Fielding, REST architectural style http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_
arch_style.htm
6

2.FEJEZET : A LAPOK
Kliens-Szerver architektúra
A kliens és a szerver el vannak különítve egymástól. A kliens nem tárol hosszú távon nagy mennyiség˝ u
adatot, ez a szerver feladata, ha a kliensnek információra van szüksége azt a szervert ˝ol fogja kérni,
viszont a szerver nem foglalkozik adatmegjelenítéssel. Ezzel a megoldással a kliens és szerver nem fog
közvetlenül függeni egymástól, így a szerver skálázható lesz, a kliens pedig egyszer˝ uen áthelyezhet ˝o.
Réteges felépítés
Az alkalmazás réteges felépítése megnövelheti a skálázhatóságot és a terhelés eloszlását az alkalmazá-
son. A kliensnek nem szükséges tudnia, hogy a kérése milyen útvonalon megy keresztül, hogyan lesz
feldolgozva és hogyan fog visszaérkezni a válasz, ez a szerver oldalon el ˝onyére fordítható úgy, hogy
különböz ˝o részek szolgálják ki a kliensek kéréseit.
2.2. URI használata
A REST szolgáltatások URI-n alapulnak2. Ha az er ˝oforrásokat elérhet ˝ové szeretnénk tenni mások szá-
mára is, szükséges valamilyen módon azonosítani, erre szolgálnak az URI-k, amelyek lehetnek URN
(Uniform Resource Name), vagy URL-ek (Uniform Resource Locator) az utóbbiak helyre vonatkozó
információkat is tartalmaznak. Egyértelm˝ uen fogják azonosítani az er ˝oforrást, a helyinformáció miatt
könny˝ u lesz dekódolni, és nem fog semmilyen technológiától függeni.
Néhány lehetséges URL
–http://mypage.com/resource/item/1
–ftp://files/abc
–http://mypage.com/add/a=1&b=2
Az URI-k meghatározásakor, megnevezzük az er ˝oforrásokat, jó ha beszédes neveket használunk, hogy
könnyen azonosítani tudjuk, egyszer˝ usíthet ˝o vele a fejlesztés, használjunk hierarchikus felépítést,
szül˝o/gyerek formában, útvonal megadásokhoz hasonlóan, ugyanakkor megadhatunk az URL-ben
különböz ˝o paramétereket is.
2.A REST URI-n alapszik http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#
sec_6_2
7

2.FEJEZET : A LAPOK
2.3. Er ˝oforrások elérése
Ahogyan a HTTP-ben ugyanígy a REST-ben is négy jól meghatározott m˝ uveletet alkalmazhatunk az er ˝o-
források manipulációjára, ezek HTTP igék (HTTP Verbs) néven ismertek: GET, POST, PUT, DELETE
3Néha csak CRUD m˝ uveleteknek nevezik ˝oket
READ – GET
UPDATE – PUT
DELETE – DELETE
CREATE – POST
GET
–Visszaad egy er ˝oforrást
–Biztonságos, nincsenek mellékhatásai, többszöri hívásra is ugyanaz lesz a hatása
–Lehet ˝oség van gyorsítótárba menteni az eredményét
–Az adatok URL-be vannak kódolva
POST
–Általában er ˝oforrások létrehozására használják
–Nem annyira biztonságos a használata, nem minden esetben ugyanaz az eredménye
–A kérés törzse tartalmazza az adatokat
PUT
–Módosít egy már létez ˝o er˝oforrást
–Minden esetben ugyanaz fog történni ha meghívjuk
DELETE
–Töröl egy létez ˝o er˝oforrást
–Minden esetben ugyanaz fog történni ha meghívjuk
3.HTTP metódusok https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
8

3. fejezet
Hasonl ´o technol ´ogi´ak
SOAP
A SOAP [17] (Simple Object Access Protocol) is üzenet alapú kommunikációs protokoll, amely általá-
ban távoli metódushívások, paramétereket és visszatérített értékeket is tartalmazhatnak. Ezek az üzenetek
azt írják le, hogy két végpont miként kommunikálhat egymással. Nem függ hálózati protokolltól, de ál-
talában HTTP-vel használják. Az üzenetek XML-alapúak, emiatt a REST-hez képest már korlátokba üt-
közhetünk. Egy egyszer˝ u példa SOAP típusú kommunikációra: a kliens felépít egy XML dokumentumot
amelybe beírja a kérését ezt elküldi a szervernek a kommunikációs csatornán keresztül, a kérés típusára
a szolgáltatások POST-ot használnak, a kérés a szerverhez érve értelmezve lesz, majd generálja a megfe-
lel˝o választ és visszaküldi a kliensnek. Mivel az üzenetek érvényes XML dokumentumok kell legyenek,
emiatt nehézkes lehet a kommunikáció, nagyméret˝ u üzenetek esetén lassíthatja a kommunikációt. Csak
a kliens használhatja a másik fél szolgáltatásait, míg REST esetén szerverek is kommunikálhatnak egy-
mással. Hátránya lehet az is, hogy nem lehet gyorsítótárazható, mert a SOAP nem támogatja a GET
m˝ uveleteket. El ˝onye, hogy HTTP és SMTP (Simple Mail Transfer Protocol) protokollok alapján is lehet
SOAP üzeneteket továbbítani, valamint a szigorú szerkezet miatt HTTPS-en is támogatva van, így biz-
tonságot nyújt mert nem engedi meg bármilyen adatok küldését, könnyen átjut a t˝ uzfalakon és proxykon
is anélkül, hogy az üzenetet módosítani kellene.
Webszolgáltatások leírása WSDL segíségével a SOAP-ban.
AWSDL is XML dokumentum, amely programozási nyelvt ˝ol független. SOAP-al együtt használható
ahol leírja, hogy egy web szoltáltatás milyen feladatokat végez el, hogyan tudjuk ezt elérni, és hogyan
történhet a meghívása. A szolgáltatásnak megadható a neve, protokoll, m˝ uveletek, paraméterek, adattí-
pusok. Az adatok interakciókat írnak le. A portType elem a rendelkezésre álló webszolgáltatás m˝ u-
veleteket határozza meg, ezekhez hozzárendelhet ˝oek ki- és bemeneti értékek. A m˝ uveletek egyirányúak,
kérés-válasz formátumban. A binding elem, protokoll specifikus elemeket tartalmaz, stílust, proto-
kollt és dekódolást határoz meg. A service elem, az adott webszolgáltatás elérési címe. Ezek mellett
megadhatóak kiegészít ˝o információk is.
9

3.FEJEZET : H ASONLÓ TECHNOLÓGIÁK
El˝onyök – hátrányok
A REST és a SOAP webszolgáltatás típusnak vannak el ˝onyei és hátrányai, nézzünk meg néhányat ezek
közül. A 3.1 ábrán látható, hogy melyek a REST illetve a SOAP er ˝osségei, gyengeségei a másikkal
szemben. A REST könnyen kezelhet ˝o pehelysúlyú, nem kell XML érvényesítéssel foglalkozni, viszont
ugyanez lehet el ˝onye a SOAP-nak mivel már el ˝ore elkészített, érvényes dokumentumot egyszer˝ u feldol-
gozni, a 3.1 kódrészletben egy egyszer˝ u SOAP üzenetet láthatunk, ami tartalmazza az üzenetre vonat-
kozó kiegészít ˝o információkat és az üzenet törzsét, ahol bizonyos adatokat kértünk le. Mivel a SOAP
üzenetben típusokat ellen ˝orizni kell ezért nehézkes lehet a megvalósítása. A REST üzenet emberi szem
számára is egyszer˝ uen olvasható. A SOAP-hoz különböz ˝o fejleszt ˝oi eszközök állnak rendelkezésre, a
REST-et pedig összetett eszközök nélkül is meg lehet valósítani.
Kódrészlet 3.1. SOAP példa
1 <? xml version ="1.0" ?>
2 <soap:Envelope xmlns:soap= "http://www.w3.org/2003/05/soap-envelope/"
3 soap:encodingStyle= "http://www.w3.org/2003/05/soap-encoding" >
4 <soap:Body>
5 <m:GetPriceResponse xmlns:m= "http://www.w3schools.com/prices" >
6 <m:Price>1.90</m:Price>
7 </m:GetPriceResponse>
8 </soap:Body>
9 </soap:Envelope>
3.1. ábra. Rest és SOAP sajátosságok1
1.REST vs SOAP http://www.infosysblogs.com/microsoft/2009/08/how_i_explained_rest_to_a_
soap.html
10

4. fejezet
A REST ´altal ´anos m ˝ uk ¨od´ese
4.1. REST – Szerver oldali általános feladatok
A web szerveren a kérés feldolgozásától a válasz generálásáig, különböz ˝o állapotok jelennek meg, amint
az a 4.1 ábrán látható.
1.Kérés- feldolgozás a beérkez ˝o URI-ból kinyeri a megfelel ˝o információkat és ezek alapján továb-
bítja, ezel ˝ott "megkérdezi" az Útvonal választót, amely alapján továbbít valamely üzleti logikáért
felel˝os részhez
2.Útvonal választás a megfelel ˝o útvonalat kiválasztja a kívánt er ˝oforráshoz
3.Feladatok elvégzése amelyeket a kliens igényelt az illet ˝o er˝oforrástól, ezután továbbít a Válasz
generálóhoz
4.Válasz generálás el˝oállítja a megfelel ˝o üzenetet és visszaküldi az eredményt a kliensnek.
4.1. ábra. Kérés feldolgozásától a válasz generálásáig végbemen ˝o folyamatok
11

4.FEJEZET : A REST ÁLTALÁNOS M ˝UKÖDÉSE
4.2. REST felhasználása
Mivel a REST egy viszonylag egyszer˝ u, könnyen megérthet ˝o architektúrán alapszik, egyre gyakrabban
használják. Programozási nyelvt ˝ol független így nem igazán lehet határok közé szorítani a megvalósítá-
sát.
Hol használják? A microservice architektúrán alapuló rendszerek szinte mindegyike REST API-t
használ, amelynek lényege hogy sok szoftver részt vehet benne és ezek kliensként és szerverként is m˝ u-
ködhetnek valamint egymással kommunikálhatnak, a kommunikációt JSON adatformátummal valósítják
meg, ezzel biztosítja az egységes kommunikációs nyelvezetet. Szinte minden nagy szervezetnek, cégnek
van valamilyen API-ja közzétéve amellyel lehet ˝ové teszi a fejlesztést azok számára, akik szeretnének
ezzel foglalkozni, ezen szervezetek nagy része REST API-segítségével osztja meg a szolgáltatásait,
er˝oforrásait. A felh ˝o alapú szolgáltatások körében is igen gyakoriak a REST alapú szolgáltatások.
Használata az alábbi esetekben indokolt:
–Ha olyan rendszert szeretnénk készíteni amely függetlenné tehet ˝o más részekt ˝ol, több kisebb elem-
re szétbontható, könnyen módosítható, ugyanakkor egységes felületet biztosít a hozzáférésre.
–Elérhet ˝ové szeretnénk tenni bizonyos er ˝oforrásokat a világ fele.
–Nem csak egyetlen entitás által szeretnénk irányítást végezni, a szerveren nem tárolunk állapotokat.
–Ha egyszer˝ uen skálázható alkalmazást szeretnénk készíteni, amely nem függ más elemekt ˝ol.
–Egyszer˝ uen karbantartható rendszert szeretnénk kiépíteni.
–Különböz ˝o adattípusokkal szeretnénk dolgozni.
Használata az alábbi esetekben nem indokolt:
–Ha merev, stabil rendszert szeretnénk készíteni.
–Szigorú biztonsági módszereket és kommunikációs protokollt szeretnénk használni, tranzakciós
m˝ uveleteket szeretnénk végezni.
–Protokoll irányú fejlesztést szeretnénk végezni.
12

4.FEJEZET : A REST ÁLTALÁNOS M ˝UKÖDÉSE
4.3. REST szolgáltatások elérése
Ahhoz hogy a szolgáltatásokat amelyek valamilyen alkalmazásszerveren futnak elérjük, kéréseket kell
intéznünk, ezt megtehetjük többféle módon is, néhány lehet ˝oséget megemlítünk:
1. Egy alkalmazás keretén belül, ahol intézhetünk szinkron vagy aszinkron kéréseket a szerverhez.
2. Böngész ˝ob˝ol, itt csak GET típusú kéréseket adhatunk meg. A válaszokat nyomon követhetjük
fejleszt ˝oi módban a network tab alatt, ahol megjelennek a kimen ˝o és bejöv ˝o információk.
3. Használhatunk erre a célra kifejlesztett REST klienseket, ahol a kérésre vonatkozó adatok adhatóak
meg, FORM-okat tölthetünk ki, fájlokat adhatunk meg, ilyen kliensek pl. Chrome – Advanced
REST Client1, Mozilla RESTClient2, Postman3, stb.
4. Parancssorból curl [16] parancs segítségével, ahol megadhatunk különböz ˝o opciókat is
1.Chrome – REST Client https://chromerestclient.appspot.com/
2.Mozilla RESTClient https://addons.mozilla.org/en-US/firefox/addon/restclient/
3.Postman http://www.getpostman.com/
13

5. fejezet
REST-et t ´amogat ´o elterjedt szoftvereszk ¨oz¨ok
A REST architektúra platformfüggetlen, ezért nagyon sok támogatást találunk hozzá, különböz ˝o prog-
ramozási nyelvek, technológiák nyújtanak eszközöket, API-kat amelyeket felhasználva könnyedén elké-
szíthetjük saját REST architektúrán alapuló alkalmazásunkat. Nézzünk meg ezen szoftvereszközökb ˝ol
néhányat.
– .NET platform lehet ˝oséget ad többféle módon is RESTful alkalmazások készítésére ilyenek, WCF
ASP.NET Web API.
– Python Django REST keretrendszer, webes API-k készítésére
– Javascript programozási nyelvben is különböz ˝o REST API keretrendszereket találunk ilyenek:
Restify1, Restberry2, Actionhero3,
5.1. Java
5.1.1. RESTful keretrendszerek
ASpring egy Java alapú keretrendszer amely sok más funkcionalitás mellett támogatja a REST szol-
gáltatásokat. Néhány egyszer˝ ubb Java EE – JAX-RS implementációt is megemlítünk, ezek Java REST
keretrendszerek amelyek RESTful típusú alkalmazások készítésére lettek kifejlesztve ilyenek például a
Jersey, Restlet4, RESTX5, Dropwizard6, stb.
5.1.2. JAX-RS Jersey
A Jersey-t [6] kiemeljük részletesebben is mivel ezzel készült az alkalmazás. Azért választottuk, a Jersey-
t, mert már valamennyire ismert volt számunkra, ugyanakkor mások is anjánlották akik hasonló tech-
nológiákkal dolgoznak. A JAX-RS (Java API for RESTful Web Services)(JSR 311 & JSR 339) [15]
1.Node-restify http://mcavage.me/node-restify/
2.Restberry http://restberry.com/
3.Actionhero http://www.actionherojs.com/
4.Restlet https://restlet.com/projects/restlet-framework/
5.RESTX http://restx.io/
6.Dropwizard http://www.dropwizard.io/0.9.2/docs/
14

5.FEJEZET : REST- ET TÁMOGATÓ ELTERJEDT SZOFTVERESZKÖZÖK
egy specifikáció amely alapján a Java REST keretrendszerek fel vannak építve. A Jersey egy referen-
cia implementáció, a fejlesztéshez kiváló dokumentáció áll a rendelkezésünkre, használható példákkal,
így könnyedén megérthet ˝o. Adattípus támogatásai Json/XML, közvetlenül írható egy Response válasz
stream és támogatja a generikus típusok visszaadását is. JAXB segítségével XML/Json leképezéseket
valósíthatunk meg.
JAX-RS Jersey bemutatás
Jersey-vel implementált webszolgáltatásokat Java Annotációkkal adhatunk meg, erre példát az 5.1 kód-
részletben találunk. Ebben a példában a szolgáltatást a sheet útvonalon érhetjük el, ezen belül találunk
még két metódust az egyiket GET típusú kéréssel érhetjük el a /SheetmusicBySheetID/{id} út-
vonalon amely egy adott ID-val rendelkez ˝o kottát ad vissza JSON formátumban, a következ ˝o metódus
nem rendelkezik külön útvonallal, azaz az osztály alapútvonalán keresztül érhetjük el egy PUT metódus-
sal, amely egy kotta típust fogad és az elmentett értéket téríti vissza.
Jersey felépítése
A Jersey több el ˝ore megírt modulból tev ˝odik össze, amelyeket felhasználva felépíthetjük a saját alkal-
mazásunkat. Lehet ˝oséget ad kliens oldali kérések felépítésére is, amelyek lehetnek szinkron és aszinkron
kérések is. Szerver oldalon er ˝oforrásokat tehetünk elérhet ˝ové, erre láthatunk példát a 5.1 kódrészletben.
Támogatást találunk különböz ˝o adattípusokra (JSON, XML, médiatípusok). Különböz ˝o Jersey verziók
között eltérések lehetnek, ezért nagyon jó leírás áll rendelkezésünkre, ha ilyen problémába ütköznénk.
Használhatunk sz˝ ur ˝oket, amelyek segítségével a kérések és a válaszok tartalmát, valamint fejléc részét
módosíthatjuk. Rendelkezésünkre állnak bizonyos biztonsági mechanizmusok is. Használhatunk MVC
modellre épül ˝o sablonokat, valamint a Jersey saját tesztelési keretrendszerét.
Jersey m˝ uködési mechanizmusa
Ahhoz, hogy használni tudjuk a Jersey szolgáltatásokat, elérhet ˝oek kell legyenek az el ˝ore megírt modu-
lok, valamint egy alkalmazásszerveren kell fusson a Jersey-vel megírt alkalmazás. Ekkor az alkalmazás-
ban megírt Jersey szolgáltatások elérhet ˝oek lesznek egy megadott útvonalon, amelyen keresztül a kérések
eljutnak a Jersey-hez, ahol fel tudja dolgozni a kéréseket, és a megfelel ˝o szolgáltatásokhoz irányít, illetve
a kérésben megadott adatokat, a szolgáltatásokat, el kell látnunk bizonyos annotációkkal (a lentiekben
ezen annotációk egy részét láthatjuk), amelyeket a Jersey értelmezni fog és ezekb ˝ol fogja tudni, hogy
pontosan melyik szolgáltatás milyen útvonalon lesz elérhet ˝o, milyen feladatokat lát el, milyen adatokat
fogad és továbbít, stb.
Milyen útvonalon lesz elérhet ˝o a szolgáltatás @Path
HTTP method annotációk @GET, @POST, @PUT, @DELETE, @HEAD
HTTP content-type annotációk opcionálisak
–@Consumes – bemenet formátuma
15

5.FEJEZET : REST- ET TÁMOGATÓ ELTERJEDT SZOFTVERESZKÖZÖK
–@Produces – kimenet formátuma
Paraméter annotációk opcionálisak
–@PathParam – az URI egy darabja
–@QueryParam – URI query paraméter
–@MatrixParam – URI mátrix paraméter
–@FormParam – POST paraméter
–@CookieParam – Cookie paraméter
–@HeaderParam – HTTP header paraméter
Példa
Kódrészlet 5.1. Java Jersey példa kód
1@Path ("sheet" )
2public class RestSheetMusic {
3
4 @GET
5 @Path ("/SheetmusicBySheetID/{id}" )
6 @Produces ({MediaType .APPLICATION_JSON })
7 public SheetMusic sheetmusic (@PathParam ("id" )Integer id ) {
8
9 SheetMusicServiceImpl smService =new SheetMusicServiceImpl ();
10 SheetMusic sm =smService .getSheetmusicById (id);
11
12 return sm ;
13 }
14
15 @PUT
16 @Consumes ({MediaType .APPLICATION_JSON })
17 @Produces ({MediaType .APPLICATION_JSON })
18 public SheetMusic addSheetMusic (User user ) {
19
20 SheetMusicServiceImpl service =new SheetMusicServiceImpl ();
21 return service .insertSheetmusic (user );
22 }
23 }
A 9.1, 9.3 és 9.4 fejezetekben részletesen is bemutatjuk, saját példán keresztül, hogy miként volt
használva a Jersey az alkalmazás készítésekor.
16

6. fejezet
RESTful architekt ´ ur ´aval k ´esz´ ıtett alkalmaz ´as
6.1. Ismertetés
Az alkalmazás zenei területen használatos, a felhasználók megoszthatják egymással kedvenc zenedarab-
jaikat, valamint kereshetnek a feltöltött zenék között, különböz ˝o sz˝ ur ˝ok alapján, megtekinthetik a kivá-
lasztott kottát valamint, lejátszhatják a hozzájuk tartozó hangfájlokat, lejátszáskor nyomon követhetik
hol tart a lejátszás amely meg lesz jelölve a kottán. Kedvenceik közé választhatnak kottákat amelye-
ket saját profil oldalukon megtekinthetnek, információkat találhatnak az adott kottához tartozó licensz
jogokról.
6.2. Funkcionalitások
1. Regisztráció – az alkalmazás használatához regisztráció szükséges, hogy a rendszer tagja lehessen
egy felhasználó
2. Bejelentkezés – Regisztráció után lehet ˝oség van bejelentkezésre, ezentúl már igénybe lehet venni
az alkalmazás szolgáltatásait. Kijelentkezési lehet ˝oség.
3. Feltöltött kották megjelenítése listaszer˝ uen a hozzájuk tartozó információkkal, a felhasználók lát-
hatják, hogy hányan tekintették meg az adott kottát.
–Keresés kotta név alapján.
–Keresés kiválasztott hangszer alapján.
4. Kotta megtekintése, a hozzátartozó hangfájl lejátszása
–Információk az adott kottáról.
–Letöltési lehet ˝oség, kotta .pdf kiterjesztésként, hangfájl hangformátumként (mp3).
5. Lejátszáskor a felhasználó követheti, hogy hol tart jelenleg a lejátszás, az oldalak automatikusan
lesznek váltva, ugyanakkor el ˝ore- és visszavihet ˝o a lejátszáskor a zene, amelyet követ a megjele-
nítend ˝o rész is.
6. Hozzáadás a kedvencekhez, valamint törlés.
7. Kedvelt kották megtekintése.
8. Hozzászólás írása egy adott kottához, megtekinthet ˝oek más felhasználók hozzászólásai, ezzel
együtt a hozzászólásra vonatkozó információk is.
9. Kotta feltöltése, különböz ˝o információk adhatóak meg.
17

6.FEJEZET : REST FUL ARCHITEKTÚRÁVAL KÉSZÍTETT ALKALMAZÁS
10. Licensz jogok megadása a feltöltend ˝o kottával kapcsolatban, a jogokról b ˝ovebb információt is
találunk.
11. Rendszergazdai felület, ahol kezelheti az oldalt, hozzáadhat az adatbázishoz új hangszereket, új
zenei stílusokat az erre jogosult személy.
18

7. fejezet
Alkalmaz ´as elk ´esz´ ıt ´es´ehez felhaszn ´alt
technol ´ogi´ak
7.1. Szerver oldal
A REST architektúra programozási nyelvt ˝ol és platformtól független és jelenleg elég sok támogatás
elérhet ˝o hozzá. Az alkalmazás szerver részét, Java nyelvben valósítottuk meg, JAX-RS Jersey alapú
implementáció segítségével amely az 5.1.2 részben már be lett mutatva.
7.1.1. Szolgáltatások elérése
Ahhoz hogy a szolgáltatásokat amelyek valamilyen alkalmazásszerveren futnak elérjük, kéréseket kell
intéznünk, ezt megtehetjük többféle módon is
Fejlesztés során használva voltak bizonyos eszközök/módszerek a szolgáltatások teszteléséhez, meg-
felel˝o m˝ uködés nyomon követéséhez, ilyenek:
1. A böngész ˝o network tab-ja amely segítségével lehet ˝oségünk van nyomon követni a beérkez ˝o, il-
letve kiment ˝o adatokat.
2. A Chrome – Advanced REST Client segítséget nyújt, ha a teszteléshez manuálisan szeretnénk
felépíteni egy kérést, ez egyszer˝ uvé tette a fejlesztési folyamatot, mivel, nehezebben tesztelhet ˝o
esetekre könnyedén tudtunk felépíteni kéréseket. A 7.1 ábrán a Chrome – Advanced REST Client-
re láthatunk egy egyszer˝ u példát, ahol az URL az alkalmazás egy szolgáltatására mutat, a kérés
típusa GET, valamint megjelenik a kérés fejléce, amelyet a Chrome – REST Client generált, ezt
módosíthatjuk igény szerint, illetve megadhatunk új értékeket is.
7.1. ábra. Kérés fejléc – Chrome – Advanced REST Client segítségével
19

7.FEJEZET : A LKALMAZÁS ELKÉSZÍTÉSÉHEZ FELHASZNÁLT TECHNOLÓGIÁK
3. Többször elég volt csak parancssorból curl parancs segítségével tesztelni a szolgáltatásokat, ha
egyszer˝ ubb kéréseket akartunk intézni. A 1. kérés megadásakor megadtunk különböz ˝o opciókat
is,-v(verbose), részletesen jeleníti meg a választ (kérés és válasz fejlécét is, a 2. válasz részben
ezeket láthatjuk), a kérés típusa GET, a -H opcióval a kérés fejlécét állíthatjuk be.
1.
curl -v GET
http://localhost:8080/BscProject/rest/sheet/getAllInstrument
-H ’Accept:application/json’
Curl parancs header eredményei, kérés és válasz eredmények
2.
> GET /BscProject/rest/sheet/getAllInstrument HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.46.0
> Accept: */*
> ’Accept:application/json’
>
< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< Content-Type: application/json
< Transfer-Encoding: chunked
< Date: Fri, 27 May 2016 15:22:35 GMT
7.1.2. Adatok tárolása
Az adatok adatbázisban vannak eltárolva, ehhez MySQL[10] adatbázis kezel ˝o rendszert használtunk. A
webszolgáltatások ezeket veszik igénybe, létrehozzák a kapcsolatot az adatbázis m˝ uveletekért felel ˝os
résszel amelyek kapcsolatot teremtenek az adatbázis szerverrel, lekérik a megfelel ˝o adatokat, elvégez-
hetnek bizonyos m˝ uveleteket velük, majd visszaküldik a választ a kliensnek. Az adatok lekérésére a
Hibernate ORM keretrendszert használtuk [8].
MySQL adatbázis szerver futtatására a XAMPP1program volt használva. Elindítva az adatbázis-
szervert, kapcsolódhatunk hozzá, elérhetjük az adatainkat melyek az adatbázisban vannak eltárolva.
Adatbázisszerverként használhattunk volna egyénileg telepített MySQL adatbázist is, vagy bármilyen
segédeszközt a MySQL futtatására. Az adatbázis felépítésére MySQL Workbench2volt használva amely
egy vizuális szerkeszt ˝o.
A 7.2 ábrán az adatbázis modell szerkezetét láthatjuk, az alkalmazás ennek alapján van felépítve,
megjelennek a tábláknak megfelel ˝o Hibernate segítségével társított Java osztályok, amelyek segítségével
történik az adatok adatbázisbeli manipulálása.
1.XAMPP https://www.apachefriends.org/
2.MySQL Workbench https://www.mysql.com/products/workbench/
20

7.FEJEZET : A LKALMAZÁS ELKÉSZÍTÉSÉHEZ FELHASZNÁLT TECHNOLÓGIÁK
7.2. ábra. Adatbázismodell diagram
21

7.FEJEZET : A LKALMAZÁS ELKÉSZÍTÉSÉHEZ FELHASZNÁLT TECHNOLÓGIÁK
7.2. Üzenet típusok
REST által támogatott üzenet típusokra jellemz ˝o, hogy emberi szemmel is könnyedén olvasható
üzenettípusokat küld. Ilyen típusok XML, JSON, HTML, sima szöveg, ugyanakkor támogatva vannak
különböz ˝o MIME azaz média típusok [14] pl. text/plain, image/jpeg, application/pdf, audio/mp3,
application/octet-stream, stb.
Szerver oldalon a megfelel ˝o üzenet típusra való alakításra többféle lehet ˝oség van:
–Felépíthetünk saját adatstruktúrákat is, a JSONObject segítségével, ahol egymásba ágyazott ada-
tokat is létrehozhatunk. Egy egyszer˝ u példát láthatunk a 7.1 kódrészletben, ahol egy számot, nevet
és beágyazott adatott mentünk el egy JSON objektumba.
Kódrészlet 7.1. JSON objetkum felépítése
1 JSONObject joEmbedded =new JSONObject ();
2 joEmbedded .put("firsname" ,"Tamas" );
3 joEmbedded .put("lastname" ,"Balla" );
4
5 JSONObject jo =new JSONObject ();
6 jo.put("age" ,"1");
7 jo.put("user" ,"tamas" );
8 jo.put("name" ,joEmbedded );
–Java objektumokat átalakíthatunk JSON, XML típusokra és vissza, ezt a mechanizmust Marshal-
ling illetve Unmarshalling-nak nevezzük. JAXB[5] (Java Architecture for XML Binding) segítsé-
gével valósul meg, amikor az objektum, egy szerializációs és deszerializációs folyamaton megy
keresztül.
Kódrészlet 7.2. Annotációval ellátott osztály – átalakítható XML, JSON típusokra
1@XmlRootElement
2public class User {
3
4 private Integer userId ;
5 private String userName ;
6 private String userPassword ;
7 private String userMail ;
8 private String userTel ;
9 private Integer userRight ;
10 private Date userLastLogin ;
11 private String userFirstName ;
12 private String userLastName ;
13 public User () {
14 }
15 //getters and setters
16 }
A 7.3 és 7.4 példában a 7.2 osztály JSON illetve XML formátumbeli megfeleltetését láthatjuk,
értékekkel feltöltve.
Kódrészlet 7.3. A 7.2 ábrán látaható POJO osztály JSON megfeleltetése
1 {
2 "userFirstName" :"Balla" ,
3 "userId" :"13" ,
4 "userLastLogin" :"2016-02-12T15:14:34+02:00" ,
5 "userLastName" :"Tamas" ,
6 "userMail" :"Tamas@gmail.com" ,
7 "userName" :"Tamas" ,
8 "userPassword" :"1234" ,
9 "userRight" :"1",
10 "userTel" :"07231689"
11 }
22

7.FEJEZET : A LKALMAZÁS ELKÉSZÍTÉSÉHEZ FELHASZNÁLT TECHNOLÓGIÁK
Kódrészlet 7.4. A 7.2 ábrán látaható POJO osztály XML megfeleltetése
1 <? xml version ="1.0" encoding= "UTF-8" standalone ="yes" ?>
2 <user>
3 <userFirstName> Balla </userFirstName>
4 <userId>13</userId>
5 <userLastLogin>2016-02-12 T15:14:34 +02:00</userLastLogin>
6 <userLastName> Tamas </userLastName>
7 <userMail> Tamas@gmail .com</userMail>
8 <userName> Tamas </userName>
9 <userPassword>1234</userPassword>
10 <userRight>1</userRight>
11 <userTel>07231689</userTel>
12 </user>
7.3. Kliens oldal
A kliens oldalon a megjelenítés HTML segítségével volt megvalósítva, használva voltak HTML5
specifikus elemek is pl. canvas ,audio . Valamint CSS Bootstrap[7] könyvtár, amely el ˝ore megírt
css elemeket tartalmaz, amely az elrendezést és a design-t segíti el ˝o. Egy példát láthatunk a 7.5
kódrészletben, ahol egy szövegmez ˝ot és egy gombot helyezünk el a felületre, használatához csupán meg
kell adnunk, hogy hol található a Bootstrap könyvtár.
Az alkalmazás kliens oldala AngularJS [3] segítségével van megvalósítva, amely egy javascript alapú
könyvtár, MVC-elv3megvalósítását szolgálja. Az adatokat betölthetjük és lekérhetjük a felületr ˝ol,
egyszer˝ uen intézhetünk aszinkron kéréseket is a webszolgáltatásokhoz, valamint az ezekre kapott
válaszokat feldolgozhatjuk. Az adatok manipulációjára használva volt jQuery is.
Kódrészlet 7.5. CSS Bootsrtap példa
1 <div class= "input-group" >
2 <input type= "text" class= "form-control" ng-model= "searchText"
3 placeholder= "Search for sheet music" >
4 <span class= "input-group-btn" >
5 <button class= "btn btn-default"
6 ng-click= "searchByName(searchText)" type= "button" >
7 <span class= "glyphicon glyphicon-search" > </span>
8 </button>
9 </span>
10 </div>
7.3.1. AngularJS
Nem módosítja egyenesen a HTML DOM-ot (Document Object Model), hanem Dependecy Injection-
t használ, ahol függ ˝oségeket állítunk be, az egyes részek között, ennek segítségével valósítható meg
az adatok, manipulálása. Ezek megvalósítása Angular direktívákkal történik, amelyekkel kiegészítjük
a HTML kódot, ezek mellett deklarálhatunk saját direktívákat is. Néhány példa Angular direktívára:
ng-app, ng-controller, ng-model, ng-view, ng-repeat stb. ezek mellett dupla kap-
csos zárójelek közé {{ expression }} megadhatunk kifejezéseket és változókat.
Az Angular a következ ˝o elemekb ˝ol épül fel: sablonok (a felületért felelnek), vezérl ˝ok, szolgáltatók, sz˝ u-
r˝ok, direktívák, cél- $scope (amelyek a modellt reprezentálják).
A 7.8 kódrészletben egy sz˝ ur ˝ot(filtert) láthatunk amely egy dátum formátumot átformáz egy más dá-
tum formátumra, ennek meghívását a 7.7 HTML kódrészletben láthatjuk.
A 7.3 ábrán láthatunk egy példát, hogyan m˝ uködik az AngularJS komponenseinek a vezérlése, és hogyan
függnek egymástól a különböz ˝o részek. Az ábra szemlélteti, hogy, hogyan történik a vezérl ˝o (Controller)
3.MVC(Model View Controler) Az adatok megjelenítésére vonatkozó elv, amely külön részekre választja a megjelenítend ˝o
adatokat a felületet valamint e kett ˝ot összekapcsoló részt.
23

7.FEJEZET : A LKALMAZÁS ELKÉSZÍTÉSÉHEZ FELHASZNÁLT TECHNOLÓGIÁK
meghívása a felületr ˝ol (Template), amely a kijelentkezésért felel, a vezérl ˝o pedig tovább hív meg külön-
böz˝o szolgáltatásokért (Service) felel ˝os részeket, ebben az esetben a felhasználó adataiért felel ˝os részt.
Az Angular lehet ˝oséget ad az alkalmazást modulokba zárni és ezeken belül fejleszteni. URL címek alap-
ján adott kontrollerekhez irányít amelyekhez HTML kódrészleteket társítva helyezi bele a f ˝ooldalba, így
nem szükséges több különböz ˝o, HTML oldalt létrehoznunk, és kontrollerek segítségével irányíthatjuk
az alkalmazásunkat. A 7.6 kódrészletben egy példát láthatunk az útvonalválasztásra, amely alapján egy
HTML oldalra irányít, és az azt vezérl ˝o kontrollerre, ebben az esetben /login URL cím érkezésekor a
LoginController vezérl ˝ore fog irányítani.
Kódrészlet 7.6. Angular: URL alapján továbbít
1angular .module (’ngMusicApp’ , [ ’ngMusicApp.filters’ ,’ngMusicApp.directives’ ,’ngMusicApp.
services’ ],
2 function ($routeProvider ,$locationProvider ) {
3
4 $routeProvider .when (’/login’ , {
5 templateUrl :’partials/login.html’ ,
6 controller :LoginController
7 });
8 });
Kódrészlet 7.7. Angular filter használata HTML oldalon
1 <p> {{ postedDate |datetime }} </p>
Kódrészlet 7.8. Dátum átformázása filter segítségével
1angular .module (’ngMusicApp.filters’ , []).
2filter (’datetime’ ,function ($filter ) {
3 return function (input ) {
4 if(input ==null ) {return "";}
5 var _date =$filter (’date’ )(new Date (input ),’MM ddyyyy -HH:mm:ss’ );
6 return _date ;
7 };
8 });
7.3. ábra. Angular m˝ uködési elv4
4.AngularJS concepts https://docs.angularjs.org/guide/concepts#service
24

8. fejezet
Alkalmaz ´as architekt ´ ura
Az architektúra a REST architektúrára épül, ez alapján kommunikál a kliens és a szerver. Az alkalmazás
architektúráját három f ˝obb részre oszthatjuk fel, a 8.1 ábrán ezt láthatjuk
– Front-end ide tartozik a kliens oldali rész, amelyet a felhasználó lát, különböz ˝o felületi elemek,
ennek a hátterében, HTML és javascript kód található. Kéréseket intéz a REST szolgáltatásokhoz,
amelyek lehetnek szinkron vagy aszinkron hívások, aszinkron hívások esetén az alkalmazás nem
lesz blokkolva, hanem értesítve lesz mikor megérkezett a válasz (ezt callback mechanizmusnak
nevezzük) ezután feldolgozza a választ és megjeleníti a felületen.
– REST API a szerver oldalon fut, és várja a kliens oldalról érkez ˝o kéréseket, eldönti, hogy hol
találja meg a kívánt kérésre a választ, ezt lekérdezve felépíti és visszaküldi a kliensnek.
– Back-end a háttérben lév ˝o szolgáltatások amelyeket a REST API felhasznál a megfelel ˝o vála-
szok el ˝oállításához. Ez a rész felel ˝os az adatbázis m˝ uveletek elvégéséért, valamint hiba esetén a
megfelel ˝o üzenet elmentéséért és a REST API fele történ ˝o üzenet küldésért.
8.1. ábra. Alkalmazás architektúra
25

8.FEJEZET : A LKALMAZÁS ARCHITEKTÚRA
8.1. Adatbázis hozzáférés megvalósítása
Az adatbázis m˝ uveletekért felel ˝os részhez, Abstract DAO factory [1] tervezési mintát használtuk. Ennek
el˝onye, hogy egyszer˝ u módon lehetne bármilyen más adatbázishoz kapcsolódni, csupán a DAO factory-t
kellene kiegészíteni a megfelel ˝o adatbázis specifikus m˝ uveletekkel. A 8.2 ábrán a jelenlegi megvalósítás
egy részét láthatjuk, egyetlen típusú adatbázis hozzáférési módszer van implementálva, amely ahogy
7.1.2 részben említve volt Hibernate specifikus. A DAO minta közzétesz factory-kat, absztrakt DAO
interfészeket. A megfelel ˝o interfész megvalósításával, az alkalmazásban a DAOFactory-tól kérünk egy
adatbázis specifikus példányt amelyet felhasználva elérhetjük az interfészeket megvalósító osztályokat,
és használhatjuk az ezekben lév ˝o adattagokat, metódusokat. A 8.1 kódrészletben a DAO tervezési minta
használatára láthatunk példát, ahol egy felhasználó adatait kérdezzük le.
Kódrészlet 8.1. DAO factory mita használata UserDAO esetén
1 DAOFactory daoFactory =DAOFactory .getJDBCInstance ();
2 UserDAO userDao =daoFactory .getUserDAO ();
3 User user =userDao .getUserById (id);
8.2. ábra. Abstract DAO factory minta
26

8.FEJEZET : A LKALMAZÁS ARCHITEKTÚRA
8.2. Alkalmazás használati esetei
Az alkalmazás használati esetei a következ ˝o módon oszthatóak fel, szerepköröknek megfelel ˝oen, vala-
mint a 6.2 fejezetben említett funkcionalitások szerint.
8.3. ábra. Használati esetek
27

9. fejezet
Alkalmaz ´as megval ´os´ ıt´asa
9.1. Jersey szolgáltatások használata
Ahhoz hogy a szolgáltatásaink elérhet ˝oek legyenek, meg kell adnunk a Jersey-nek, hogy hol találhatóak
meg, valamint azt, hogy milyen útvonalon (URI) szeretnénk elérhet ˝ové tenni. Ezt egyszer˝ uen megte-
hetjük a projektünk web.xml fájljában, amely segítségével a Jersey feldolgozza a beérkez ˝o adatokat,
társítja a megfelel ˝o java osztályhoz útvonal alapján, amelyet megadtunk a @Path paraméter segítségé-
vel. Ezeket ugyanúgy használhatjuk, mint egyszer˝ u java webes alkalmazások esetén azaz szervleteket
definiálunk, viszont az osztályt ahol deklaráljuk a szervletet nem kell megadnunk ezt elvégzi a Jersey,
helyette JAX-RS annotációkkal ellátott osztályokat adunk meg (REST szolgáltatások) és ezeket adjuk
meg a Jersey-nek paraméterként.
A 9.1 kódrészletben láthatjuk, ahogy a Jersey szervletnek megadjuk paraméterként a saját REST
szolgáltatásaink elérési útvonalát, package elérésként. A szolgáltatások elérési útvonalainak megadását a
<servlet-mapping> xml tag-ek között találhatjuk, ahol az el ˝oz˝oleg definiált szervletet kapcsoljuk
össze a megfelel ˝o útvonallal.
Kódrészlet 9.1. web.xml Jersey szolgáltatások elérése, mappelése
1 <servlet>
2 <servlet-name> Jersey </servlet-name>
3 <servlet-class> com.sun.jersey .spi.container .servlet .ServletContainer </servlet-class>
4 <init-param>
5 <param-name> com.sun.jersey .config .property .packages </param-name>
6 <param-value> edu.ubb.bsc.rest </param-value>
7 </init-param>
8 <load-on-startup>1</load-on-startup>
9 </servlet>
10
11 <servlet-mapping>
12 <servlet-name> Jersey </servlet-name>
13 <url-pattern>/ rest /*</url-pattern>
14 </servlet-mapping>
9.2. Az alkalmazás keretén belül elérhet ˝o REST szolgáltatások
Az alkalmazás fejlesztésekor figyelemmel követhetjük az elérhet ˝o REST szolgáltatásokat és a hozzájuk
tartozó információkat, amelyek megkönnyíthetik a fejlesztés folyamatát. A 9.1 ábrán a saját alkalma-
zás esetében láthatjuk ezeket, melyeket az Eclipse EE fejleszt ˝oi környezet jelenített meg. Egy REST
szolgáltatás esetében megjelen ˝o információk:
–A kérés típusa: GET, POST, stb.
–Az útvonal amelyen elérhet ˝o az adott szolgáltatás.
–Fogadott és el ˝oállított adatok típusa.
28

9.FEJEZET : A LKALMAZÁS MEGVALÓSÍTÁSA
–Az adott osztály/metódus amely elvégzi a szolgáltatás feladatait.
9.1. ábra. Elérhet ˝o REST szolgáltatások
9.3. Válasz objektumok el ˝oállítása
Szerver oldalon valamilyen módon el ˝o kell állítanunk a szolgáltatásokban a válaszokat, amelyeket
a kliens fogadni és értelmezni tud. A 9.2 kódrészben bemutatottak alapján különböz ˝o típusú üze-
neteket állíthatunk el ˝o. A fogadott és el ˝oállított üzenetek típusait megadhatjuk a @Consumes il-
letve @Produces annotációk segítségével, ezek típusai lehetnek nem csak JSON és XML típu-
sok, hanem különböz ˝o médiatípusok, amelyeket megadhatunk a MediaType kulcsszóval, valamint
egyszer˝ u szöveg: TEXT_PLAIN ,HTML_PLAIN , formok feldolgozása: MULTIPART_FORM_DATA ,
stb., ezen típusok megadása a következ ˝o formában is lehetséges: "application/json" ,
"multipart/form-data" ,"text/plain" stb.
Kódrészlet 9.2. Kérések és válaszok típusai
1 @Consumes ({MediaType .APPLICATION_JSON ,MediaType .APPLICATION_XML ,})
2 @Produces ({MediaType .APPLICATION_JSON ,MediaType .APPLICATION_XML })
3 public List <SheetMusic >SheetMusicByInstrumentID (SheetMusic sheetmusic ) {
4 //implementation
5 }
A metódusok visszatérített értékei lehetnek: void, Response, GenericEntity vagy más Java típusok.
void visszatérítési típus esetén a válasz üres törzs (body) résszel tér vissza és 204-es állapot kóddal.
29

9.FEJEZET : A LKALMAZÁS MEGVALÓSÍTÁSA
Response típusú válaszoknak beállíthatjuk a állapot kódjait is, valamint a törzs részét amely lehet
null is ebben az esetben az állapot kód 204 lesz, különben 200. A Response típusú válaszok a
javax.ws.rs.core.Response; könyvtárban találhatóak meg. Használatuk pedig a követ-
kez˝o módok valósítható meg:
Response.status(200).entity("Response is OK").build();
Java típusok is lehetnek visszatérített értékek: String, vagy saját típusokat is megadhatunk, ha ren-
delkeznek a @XmlRootElement annotációval. Az el ˝oállított üzenetek lehetnek akár listák is
ahogyan a 9.2 kódrészletben is láthatjuk.
9.4. Szolgáltatás igénybevétele felhasználói oldalról
A 9.2 ábrán annak a folyamatát láthatjuk, hogy, hogyan történik meg egy kotta és a hozzá tartozó infor-
mációk lekérése a felhasználó interakciójától a válasz megérkezéséig.
9.2. ábra. Kotta lekérésének folyamatát szemléltet ˝o szekvenciadiagram
Az oldal betöltésekor AngularJS segítségével aszinkron hívást intézünk a REST szolgáltatás fele.
Tudjuk, hogy pontosan melyik kottának az adatait kell lekérnünk ezt a kérés URL-jébe is belefoglaljuk,
ezt a jelenleg érkezett kérés URL-jéb ˝ol nyerjük ki, amelyet a felhasználó az adott kottára kattintáskor
kiválasztott, ha az URL-b ˝ol nem tudtuk kinyerni a megfelel ˝o üzenetet akkor a kérés nem fog megtör-
ténni, ugyanígy, ha sikerült kinyerni az információt viszont az adott számú kotta nem található meg
az adatbázisban ez esetben megjelenik egy megfelel ˝o hibaüzenet. A 9.3 kódrészletben egy ilyen típusú
aszinkron hívást láthatunk. Miel ˝ott a kérés megtörténne ellen ˝orizve van, hogy a felhasználónak van-e
joga az adott oldal megtekintéséhez, ha nincs akkor ez esetben is megjelenik egy megfelel ˝o üzenet, hogy
be kell jelentkeznie.
30

9.FEJEZET : A LKALMAZÁS MEGVALÓSÍTÁSA
Kódrészlet 9.3. AngularJS aszinkron hívás
1 $http .get(url +"getSheetmusicBySheetID/" +id).
2 success (function (response ) {
3 //handling response
4 }
A kérés fogadását szerver oldalon a REST szolgáltatás végzi, 9.4 kódrészletben láthatjuk, amely egy
Java osztály metódusa, a megfelel ˝o annotációkkal ellátva, amelyeket az 1, 4-6 terjed ˝o sorokban találunk,
a metódus fejléce tartalmaz egy paramétert is, amelyet az URL-b ˝ol nyerünk ki, a továbbiakban lekér-
dezzük az adatbázisból, a megfelel ˝o azonosítóval rendelkez ˝o kottát, ezek mellett naplózást is végzünk.
Felépítjük a megfelel ˝o válasz objektumot, a lekért kotta információi alapján, a szolgáltatás a háttérben
elvégzi a megfelel ˝o szerializációs m˝ uveleteket, JSON típusra alakítva, így ebben a formában fogjuk
visszaküldeni a kliensnek a választ.
Kódrészlet 9.4. Jersey REST szolgáltatás
1@Path ("sheet" )
2public class RestSheetMusic {
3
4 @GET
5 @Path ("/getSheetmusicBySheetID/{id}" )
6 @Produces ({MediaType .APPLICATION_JSON })
7 public SheetMusic getSheetmusicBySheetID (@PathParam ("id" )Integer id ) {
8 SheetMusicServiceImpl smService ;
9 SheetMusic sm =new SheetMusic ();
10 try {
11 smService =new SheetMusicServiceImpl ();
12 sm=smService .getSheetmusicById (id);
13
14 log.info ("Get Sheetmusic bysheet music ID");
15
16 } catch (ServiceException e ) {
17 log.error ("Error ingetting sheetMusic" ,e);
18 }
19 return sm ;
20 }
21 }
9.5. Fejlesztéshez használt eszközök
Programozási környezet
A Java egy magas szint˝ u programozási nyelv, amely azt jelenti, hogy nagyon sok el ˝ore megírt modul áll
a programozók rendelkezésére, amely nagy mértékben megkönnyíti a programozók dolgát. Mivel saját
virtuális gépen fut, ezért nem függ az operációs rendszert ˝ol azaz platformfüggetlen, csupán a megfelel ˝o
virtuális gépet kell telepítenünk amelyet tartalmaz a Java Runtime Environment (JRE).
Az alkalmazás elkészítéséhez a java 1.8 verzióját használtuk, a fejlesztés Eclipse Mars.2 Release (4.5.2)
fejleszt ˝oi környezetben történt, Java EE (Enterprise Edition) nézetet felhasználva.
A küls ˝o függ ˝oségek beállítására maven project management és build rendszert használtunk (3.3.9
verzió), ennek köszönhet ˝oen egyszer˝ uen lehet megadni el ˝ore megírt modulokat, és használni azokat
valamint az alkalmazás futtatását, tesztelését, telepítését segíti. Használata egyszer˝ u, a projekt maven tí-
pusú kell legyen, amely rendelkezik egy pom (Project Object Model) fájlal ahol megadhatjuk projektünk
31

9.FEJEZET : A LKALMAZÁS MEGVALÓSÍTÁSA
azonosító információit, függ ˝oségeket amelyeket egy küls ˝o szerverr ˝ol betölt a saját lokális repsitory-ba,
ezekre hivatkozva a projektben fel lehet használni ˝oket. [9]
Más eszközök
–A fejlesztés során használva volt a git verziókövet ˝o rendszer is, ezért ha szükséges volt vissza
lehetett térni el ˝oz˝o verziókra. A forráskód megtalálható a következ ˝o címen https://github.
com/ballatomi/allamvizsga . Git kliensként SourceTree1volt használva, vagy néha csak
parancssor.
–Hibák megtalálására, javítására használva volt naplózási mechanizmus, ahol slf4j , illetve
logback megvalósításokat vettünk igénybe. A 9.5 kódrészletben láthatjuk, hogyan használhatjuk
a naplózást. A beállításokat a logback.xml fájlban végeztük el, ennek segítésével a bizonyos szint˝ u
adatokat a standard kimenetre vagy fájlba irányítottunk.
Kódrészlet 9.5. Példa naplózásra
1 Logger log =LoggerFactory .getLogger (Authenticate .class );
2 log.error ("Log test error" );
–Az adatbázis táblák mappelése Hibernate megvalósításra az Eclipse Hibernate Tool segítségével
történt, amely automatikusan létrehozta az adatbázisban lév ˝o tábláknak megfelel ˝o Java osztályo-
kat, illetve különböz ˝o segéd állományokat.
9.6. Válasz feldolgozása kliens oldalon
A szerver oldalról érkez ˝o válaszok, javascript segítségével voltak feldolgozva. Angular segítségével
küldött aszinkron kérésekre a válasz JSON objektumok formájában érkezett, ezeknek a mez ˝o értékeire
egyszer˝ uen a pont operátorral hivatkozhatunk, lista válaszobjektumok esetében is egyszer˝ uen végigjár-
ható az adott objektum. A 9.6 kódrészletben egy válasz feldolgozást láthatunk amely JSON típusú üzenet
és több elemet is tartalmaz, azaz tömb típusú, a feldolgozás eredményét az Angular $scope változójába
mentjük amelyet elérhetünk a felületen. Ezen adatok megjelenítését a felületen a 9.7 kódrészletben
láthatjuk.
Kódrészlet 9.6. JSON tömb válasz objektum feldolgozása
1$http .get(urlSheetMusic +"getAllSheetMusic" ).success (function (response ) {
2 $scope .Sheetmusic =response .sheetMusic ;
3
4 var respLength =response .sheetMusic .length ;
5 for (var i = 0; i<respLength ;i++) {
6 $scope .Sheetmusic [i].uploadDate =response .sheetMusic [i].uploadDate ;
7 }
8 });
1.SourceTree official site https://www.sourcetreeapp.com/
32

9.FEJEZET : A LKALMAZÁS MEGVALÓSÍTÁSA
Kódrészlet 9.7. JSON objektum végigjárása HTML oldalon
1 <tr ng-repeat= "sheet inSheetmusic" >
2 <td>
3 <p>{{ sheet .user .userName }}</p>
4 <p>{{ sheet .viewsNum }}</p>
5 <p>{{ sheet .uploadDate }}</p>
6 <p>{{ sheet .songGenre .songGenreName }}</p>
7 </td>
8 </tr>
9.7. Kihívások/érdekességek a fejlesztés során
Fájlok megjelenítése
A fejlesztés során, különböz ˝o fájl objektumok is tárolva voltak az adatbázisban, ezek is JSON objektu-
mokban voltak tárolva és szállítva a hálózaton keresztül, majd tárolva az adatbázisba. Lekérdezéskor is
ugyanez volt a folyamat csak fordított irányban.
Kliens oldalon a válasz fájl része is string típusként érkezik ezért vissza kell alakítanunk ah-
hoz, hogy meg tudjuk jeleníteni, az ezt elvégz ˝o kódrészletet a 9.8 részben láthatjuk, ahol karakterenként
másoljuk át az adatokat egy tömbbe, amely int típusú lesz.
Kódrészlet 9.8. JSON tömb válasz objektum feldolgozása
1var data =atob (response .sheetMusic .filePdf );
2var pdfAsArray =new Array (data .length );
3for (var i = 0; i<data .length ;i++) {
4 pdfAsArray [i] = data .charCodeAt (i);
5 }
6var pdfUint =new Uint8Array (pdfAsArray );
A válasz pdf megjelenítéséhez egy javascript könyvtár a PDFJS[2] volt használva, ugyanennek se-
gítségével voltak feldolgozva és kinyerve a megfelel ˝o információk a kotta követésére.
A kotta követése
A hangfájlt betöltve különböz ˝o figyel ˝ok (listenerek) vannak használva amelyek bizonyos események-
kor aktiválódnak. Lehet ˝oség van annyi részre felosztani a pdf-et ahány ütemb ˝ol áll. Ismerve a hangfájl
hosszát, lejátszáskor váltani tudunk a felosztott részek között.
Fájl adatok kezelése szerver oldalon
A Hibernate típusú adatbázis hozzáférés segítségével, egyszer˝ uen megoldható volt a fájlok manipulálása,
viszont gondot okozott a Hibernate alapértelmezetten beállított naplózása, amely kiíratta a manipulálan-
dó adatot, így ha a fájl kissé nagyobb méret˝ u volt, akkor elég sokáig eltartott a beszúrás/lekérdezés,
az elején nem sikerült, rájönni, hogy mi okozza a lassúságot, viszont a Hibernate naplózási szintjének
átállításával, megoldódott a probléma.
33

10. fejezet
Felhaszn ´al´oi dokument ´aci´o
10.1. Alkalmazás üzembe helyezése
Webes alkalmazások esetén ahhoz, hogy elérhessük a szolgáltatásokat ki kell telepítenünk egy alkalma-
zás szerverre. Java webes projektek esetén ez .war1formátumban lesz kitelepítve amely tartalmazza a
szükséges er ˝oforrásokat amelyeket az alkalmazás felhasznál, leíró állományokat és bináris .class fájlokat
amelyek a java program futásához szükségesek.
Ahhoz hogy az alkalmazás m˝ uködjön el ˝oször el kell indítanunk az adatbázis szervert, amelyen megtalál-
ható a saját adatbázisunk, ezt betölthetjük lefuttatva a megfelel ˝o .sql script fájlt, ezek után kapcsolódha-
tunk az adatbázisra és m˝ uveleteket végezhetünk.
Az alkalmazást futtathatjuk többféle módon is
1. Az alkalmazást import-oljuk az eclipse fejleszt ˝oi környezetbe (ebben az esetben rendelkeznünk
kell a teljes forráskóddal), itt a beépített szerverre telepítjük az alkalmazást és futtatjuk, el ˝oször
telepítenünk kell a beépített szervert, ajánlott a Tomcat v7.0 [11] ennek segítségével volt készítve
az alkalmazás.
2. Ugyancsak import-oljuk az alkalmazást eclipse-be viszont, maven segítségével futtatjuk, itt meg
kell adnunk hogy milyen szerveren szeretnénk futtatni, pl. cél (goals) opciónál jetty:run , vagy
megadhatunk más szervereket.
3. Talán a legegyszer˝ ubb módja a telepítésnek és futtatásnak a parancssorból való futtatás maven
segítségével, amelyet a következ ˝o paranccsal tehetünk meg: mvn jetty:run ebben az esetben jetty
szerverre lesz telepítve és futtatva az alkalmazás.
10.2. Alkalmazás használata/esettanulmányok
Sikeres telepítés után az alkalmazást böngész ˝ob˝ol a[:szerver][:port]/BscProject/ címen
érhetjük el, ahol a bejelentkezési oldal jelenik meg. Az alkalmazást csak regisztrált felhasználók vehetik
igénybe, ha még nem regisztráltunk akkor ezt megtehetjük a Sign Up Here linkre kattintva, ahol
kitöltve az adatokat, regisztrálhatunk, ha a regisztráció sikeres volt megjelenik a megfelel ˝o üzenet. Ezután
1.WAR – Web application ARchive
34

10. FEJEZET : FELHASZNÁLÓI DOKUMENTÁCIÓ
Sign In -re kattintva visszatérhetünk a bejelentkezési oldalra amelyet a 10.1 ábrán is láthatunk, itt
megadva a felhasználónevet és jelszót bejelentkezhetünk a rendszerbe.
10.1. ábra. Bejelentkezési oldal
Bejelentkezve az alkalmazás kezd ˝ooldalát láthatjuk, ezt láthatjuk a 10.2 ábrán is, ahol listaszer˝ uen
találhatóak a betöltött kották és a hozzájuk tartozó információk, rákereshetünk kottákra a címeik alapján,
ha a keresésnél nem adunk meg semmit akkor az újra betölti a kottákat, sz˝ urhetünk bizonyos információk
szerint. Ha meg szeretnénk tekinteni a kottát/le szeretnénk játszani, akkor a címére vagy a képre kattintva
tovább léphetünk.
10.2. ábra. Listázott kották megtekintése
35

10. FEJEZET : FELHASZNÁLÓI DOKUMENTÁCIÓ
Rendszergazdai jogokkal rendelkez ˝o felhasználó is ugyanúgy igénybe veheti az oldal funkcionalitá-
sait, mint bármilyen más felhasználó, de ezek mellé bevihet a rendszerbe hangszerre és zenei stílusokra
vonatkozó információkat, valamint törölhet ezek közül(stílusok esetén törl ˝odni fognak a feltöltött kották
is), az alkalmazásnak ezt a részét a 10.3 ábrán láthatjuk.
10.3. ábra. Rendszergazdai felület kezelése
A 10.4 ábrán az alkalmazás kotta megjelenít ˝o illetve lejátszó funkcionalitását láthatjuk. Ezen az
oldalon már b ˝ovebb információt találunk az adott kottáról, lehet ˝oségünk van kedvelni a kottát, vagy
visszavonni a kedvelést, a kedvelt kottákat valamint saját adatainkat megtekinthetjük a My Profile
oldalon amit elérhetünk a fejlécb ˝ol a My Profile vagy a felhasználónevünkre kattintva. Emailt írhatunk
a felhasználónak aki az adott kottát feltöltötte, hozzászólást írhatunk a kottához, valamint megtekintet-
jük mások hozzászólásait. A lejátszás gombra kattintva elindul a kottához tartozó zene, valamint a kottán
megjelenik soronként, hogy hol tart a lejátszás, ha egy adott soron tovább haladtunk akkor az el ˝oz˝o elhal-
ványodik, ha a kotta több oldalból áll az oldal végéhez érve a következ ˝o oldalra fog váltani. A lejátszás
jelz˝ot módosítva el ˝ore- vagy vissza mehetünk a lejátszásban ezzel együtt az oldalak is automatikusan
fognak változni. Lejátszásnál beállíthatjuk a hanger ˝ot is.
Feltölthetünk a rendszerbe kottákat az Update Sheet music oldalon, megadva a megfelel ˝o in-
formációkat, ha valamit nem adtunk meg helyesen a rendszer jelezni fogja, sikeres feltöltés esetén vissza-
igazolást kapunk. A kottákra megadhatunk licensz jogokat amelyekr ˝ol b˝ovebben is olvashatunk az Abo-
ut, License fül alatt.
36

10. FEJEZET : FELHASZNÁLÓI DOKUMENTÁCIÓ
10.4. ábra. Adott Kotta megtekintése
37

11. fejezet
K¨ovetkeztet ´esek
Az alkalmazás fejlesztése során, REST segítségével a kliens és szerver oldal között egyszer˝ uvé vált
az adatok küldése, így nyugodtan lehetett az alkalmazás más részeit is fejleszteni. A fejlesztés során
sikerült több tapasztalatot szerezni, és új technológiákat jobban megismerni, jelent ˝os szakmai fejl ˝odést
elérni. Összegezve a projekt sikeresnek mondható, mivel a tervezett funkcionalitások megvalósultak.
11.1. Továbbfejlesztési lehet ˝oségek
Az alkalmazást lehet ˝oség lenne több irányban is továbbfejleszteni:
–a kottákat pontosabban feldolgozni és ez alapján követni a lejátszást, valamint olyan eseteket is
lekezelni, amelyek jelenleg nincsenek megvalósítva (ismétléseket is belevonni)
–A kották feldolgozása szerver oldalon, ehhez egy olyan REST szolgáltatást készíteni, amely csak
a lejátszandó rész koordinátáit jeleníti meg.
–A felhasználók feltölthetnének kottákat, amelyekért fizetni kell, más felhasználók, egy részletet
megtekinthetnének a kiválasztott kottából, fizetve pedig letölthetik az adott kottát.
–A felhasználóknak többféle funkcionalitást nyújtani, egymás követése, értesítés érkezzen, ha egy
általunk követett felhasználó, új kottákat töltött fel, csoportokat létrehozni, személyekre rákeresni,
stb.
38

Irodalomjegyz ´ek
[1]. Core j2ee patterns – data access object. http://www.oracle.com/technetwork/
java/dataaccessobject-138824.html , 2007.
[2]. Pdfjs hivatalos odala. https://mozilla.github.io/pdf.js/ , 2012.
[3]. Angularjs hivatalos oldala. https://angularjs.org , 2013.
[4]. Json (javascript object notation). http://www.json.org/ , 2013.
[5]. Jaxb hivatalos odala. https://docs.oracle.com/javase/tutorial/jaxb/
intro/index.html , 2015.
[6]. Jersey hivatalos oldala. https://jersey.java.net/ , 2015.
[7]. Bootstrap hivatalos oldala. http://getbootstrap.com/ , 2016.
[8]. Hiberante hivatalos odala. http://hibernate.org/ , 2016.
[9]. Maven hivatalos oldala. https://maven.apache.org/ , 2016.
[10] . Mysql hivatalos odala. https://dev.mysql.com/doc/ , 2016.
[11] . Tomcat hivatalos oldala. http://tomcat.apache.org/tomcat-7.0-doc/ , 2016.
[12] Roy Thomas Fideling. Architectural Styles and the Design of Network-based Software Architectu-
res. PhD thesis, Univerity of California, Irvine, 2000.
[13] Roy Thomas Fideling. Representational state transfer (rest), 2000.
[14] Ned Freed. Media types. http://www.iana.org/assignments/media-types/
media-types.xhtml , 2013.
[15] Marek Potociar Santiago Pericas-Geertsen. Jax-rs hivatalos dokumentáció. https://
jax-rs-spec.java.net/ , 2014.
[16] Daniel Stenberg. Curl hivatalos oldala. https://curl.haxx.se/docs/manpage.html ,
2014.
[17] Brian Suda. Soap web services, 2003.
[18] R. Fielding T. Berners-Lee, J. Gettys. w3 hivatalos oldala. https://www.w3.org/
Protocols/ , 2014.
39