SPECIALIZAREA INFORMATICǍ ROM ÂNǍ LUCRARE DE LICENȚĂ ACCESAREA SERVICIILOR WEB PRIN INTERMEDIUL TELEFONELOR MOBLIE Conducător științific Lect. Dr…. [607605]

UNIVERSITATEA BABEȘ -BOLYAI CLUJ -NAPOCA

FACULTATEA DE MATEMATICǍ ȘI INFORMATICǍ

SPECIALIZAREA INFORMATICǍ ROM ÂNǍ

LUCRARE DE LICENȚĂ

ACCESAREA SERVICIILOR WEB
PRIN INTERMEDIUL TELEFONELOR
MOBLIE

Conducător științific
Lect. Dr. Vancea Alexandru

Absolvent: [anonimizat]

2019

2
Cuprins
1. Introducere ………………………….. ………………………….. ………………………….. ………………………….. .. 3
2. Servicii Web ………………………….. ………………………….. ………………………….. ………………………….. 5
2.1 Protocolul HTTP ………………………….. ………………………….. ………………………….. ……………… 5
2.2 Descrierea problemei ………………………….. ………………………….. ………………………….. ……… 8
2.3 Servicii Web RPC, SOAP și REST ………………………….. ………………………….. …………….. 12
2.3.1 RPC (Remote Procedure Call) ………………………….. ………………………….. …………….. 12
2.3.2 SOAP (Simple Object Access Protocol) ………………………….. ………………………….. 13
2.3.3 REST (Representational State Transfer) ………………………….. …………………………. 16
3. Tehnologii folosite ………………………….. ………………………….. ………………………….. ………………. 19
3.1 Tehnologii folosite pentru aplicația server ………………………….. ………………………….. .. 20
3.1.1 Flask ………………………….. ………………………….. ………………………….. ……………………….. 21
3.1.2 SQLAlchemy ………………………….. ………………………….. ………………………….. …………… 24
3.2 Tehnologi folosite pentru aplicația client ………………………….. ………………………….. …. 29
3.2.1 React ………………………….. ………………………….. ………………………….. ……………………….. 30
3.2.2 MobX ………………………….. ………………………….. ………………………….. ……………………….. 31
4. Aplicația EasyParking ………………………….. ………………………….. ………………………….. …………. 33
4.1 Arhitectură ………………………….. ………………………….. ………………………….. …………………….. 33
Bibliography ………………………….. ………………………….. ………………………….. ………………………….. ….. 37

3

1. Introducere

În orașele cu un grad de ocupare ridicat, locurile de parcare din zonele de interes devin
o resursă pe care oamenii și autoritățiile trebuie să o gestioneze inteligent. Astfel că, un
studiu [1] arată că într -un oraș ca New York -ul, oamenii pierd în medie aproximativ o sută
șapte ore pe an căutând un loc de parcare liber.
Acest lucru aduce daune cuantificabile din punctul de vedere al timpului pierdut, banilor
irosiți pe combustibilul consumat sau a emisiilor de dioxid de carbon din atmosferă care se
produc în plus.
Studiul arată media de ore din cele mai aglomerate 10 orașe din Statele Unit e ale
Americii și calculează o sumă aproximativă care reprezintă daunele estimate pentru aceste
orașe. Aceasta se ridică la 72,7 miliarde de dolari pentru anul 2017, anul în care compania
INRIX a efectuat studiul. De asemenea căutarea unui loc de parcare î ntr-un interval orar în
care traficul este deja congestionat duce la o îngreunare suplimentară datorată faptului că
pentru a putea găsi un loc de parcare pe o stradă, șoferul trebuie să încetinească pentru a
vedea din timp locul liber și să oprească trafic ul pentru o perioadă pentru a putea parca.
Din studiu mai aflăm că din cei 6000 de șoferi americani care au răspuns la sondaj , un
procent de 63% au raportat că au evitat să conducă spre o destinație datorită dificultății de
a găsi un loc de parcare. Acest lucru are un impact negativ asupra afacerilor locale și a
economiei. Din aceștia 39% au evitat destinațiile de cumpărături, 27% aeroporturile, 20%
cabinetele medicale.
Toate aceste lucruri fac locurile de parcare să fie o resursă indispensabilă a secolulu i
XXI care trebuie gestionate prin sisteme inteligente pentru a putea fi maximizată eficiența
folosirii lor.
Desigur, există deja aplicații pe piață care abordează și încearcă să rezolve problema
aceasta, însă soluția propusă de noi abordează problema dife rit de celelalte soluții de pe
piață din cauză că majoritatea se focusează pe optimizarea gestiunii locurilor de parcare
din parcările private aflate într -un oraș sau parcările din aeroporturi. Aplicația dezvoltată în
cadrul acestei lucrări se concentrează pe eficientizarea folosirii locurilor de parcare din
parcările mall-urilor.

4
Noi propunem o soluție care se bazează pe datele oferite de anumiți senzori care sunt
montați pe locurile de parcare și trasmit dacă acesta este ocupat sau liber. A stfel că un
șofer care folosește aplicația va vedea numar de locuri libere in parcare și chiar unde există
locuri libere , în concluzie va beneficia de economisirea timpului și combustibilului.
Aplicația este dezvoltată ca un serviciu pentru a oferi posibilitatea prezentă rii
informațiilor stocate pe un server . Astfel că aplicația constă de fapt dintr -un servicu REST
(Representational State Transfer) și o aplicație web care oferă informațiile șoferilor în timp
real despre locurile de parcare din zona lor de interes.
Aceste componente vor fi prezentate în următoarele capitole ale lucrării care vor detalia
conceptele, ideile și tehnologiile folosite în realizarea acestei aplicații și de asemenea vom
prezenta comparații cu anumite aplicații care abordează aceiași problemă.

5
2. Servicii Web
Ne vom referi în această lucrare la World Wide Web (WWW) pe scurt, Web sau www.
Astfel că web -ul este un model, un spațiu informațional prin care elementele de interes,
numite și resurse, sunt identificate prin identificatoare globale denumite Uniform Resource
Identifier (URI). [2] Informațiile sunt legate între ele prin hyperlinks, care reprezintă noduri
logice prin care se face navigarea între resurse. Astfel că, protocolul de comun icare în
sistemul web este Hypertext Transfer Protocol (HTTP), protocol care are ca scop transferul
de hipertext, text care conține hiperlegături și care facilitează navigarea structurată între
resurse prin accesarea URI -urilor acestora.
În continuare vom prezenta pe scurt protocolul HTTP și conceptul de aplicație web
pentru a putea crea un context în care putem discuta despre conceptul de interes din acest
capitol, și anume Servicii Web și în special Servicii Web RESTful.

2.1 Protocolul HTTP
Protocolul HTTP a fost inițiat de Tim Berners -Lee și fiind protocolul de transfer utilizat
de Web se află la nivelul de aplicații al stivei de protocloale TCP/IP (Transmission Control
Protocol/Internet Protocol). [3] Conceptele fundamentale ale protocolului sunt cererea și
răspunsul, acțiuni realizate de către client respective server pentru acesarea, modificarea,
înlocuirea sau ștergerea resurselor. [3] Clientul este cel care inițiază comunicarea cu o
cerere ce poate fi descrisă că fiind un mesaj cu o structura prestabilită ce conține detalii
precum tipul de operație pe care clientul vrea să o facă asupra resursei, datele necesare
pentru operația respectivă și URI-ul la care se găsește resursă. [3] Serverul este cel
care procesează aceste cereri și răspunde clientului cu un mesaj, de asemenea cu o
structură prestabilită și conține delatii despre procesarea cererii precum un code de
stare prin care serverul descrie starea cere rii pe care a procesat -o, dacă această a putut
fi procesată sau nu cu success. [3] Răspunsul poate să mai conțînă, in cazul care cererea
a fost procesată cu success de care server, resursă vizată de către client,
fie ea o pagină HTML(Hypertext Markup Language, un fișier video sau audio,
un fișier XML(Extensible Markup Language), etc.

6
Datorită faptului că serverul poate răspunde cu toate aceste tipuri de date unui client
face ca protocolul HTTP să fie versatil și să corespundă unei game variate de cerințe și
nevoi cu caracter generic care s -au dezvoltat de -a lungul timpului.
Comunicarea dintre un server și un client este inițiată de către cel din urmă prinț -o
cerere care are o structură asemănătoare celei din figura de mai jos.
În această imagine se pot identifica componentele unei cereri. Prima informație este
metoda de acces. [3] Aceste metode sunt importante în contextual serviciilor web deoarece
această corespunde cu acțiunea pe care o poate efectua serverul asupra unei resurse.
Pentru foarte mult timp web -ul a fost folosit în interacțiuni om -mașină astfel cele cele mai
folosite metode de acces sunt GET și POST. Aceste metode pot fi observate în
comportmentul browserelor care afișează o pagină folosind o cerere specificată cu metoda
GET, sau care trimit unui server date transmise de către utilizator printr -o cerere specificată
cu medoda POST. Se folosesc și alte metode precum PUT, DELETE, TRACE, CONNECT,
în special în contextual serviciilor web care încearcă să faciliteze mai mult decât
comunicarea om -mașină. [3]
Răspunsul serverului are o structură pre cum se poate identifica în imaginea de mai jos.
Fig. 1 Exemplu de cerere HTTP

7

În răspuns se pot identifica elementele importante precum codul de stare și dacă e
cazul, tipul conținutului din răspuns cu lungimea răspunsului și resursa propriu zisă care e
reprezentată de corpul răspunsului.
Capacitățile protocolului HTTP nu sunt puse în valoare atunci când vorbim de acesarea
paginilor web de către utilizatori, deoarece aceștia nu sunt interesați de aceste detalii de
funcționare, browser -ul gestionandu -le pentru utilizatori. Aceste elemente sunt importatnte
atunci când vorbim de serviciile web deoarece orice variație poate schimba modul în care
serverul cu care dorim să comunicăm va răspunde și acționa. Ace st model de comunicare
structurat este benefic atunci când clientul este de fapt un alt server care folosește
structura mesajului de cerere pentru a specifica detaliile interacțiunii cu resursele care se
găsesc pe celălat server. De asemenea acest model of eră serverului care gestionează
cererea și trimite răspunsul adecvat cererii niște limite bine definite dar și un grad de
liberate în care să funcționeze pentru că clientul, adică celălat server, să poată interpreta
răspunsul.
Protocolul de comunicare HTTP dispunde de un cacarter stateless, adică poate deservii
cereri concurente de la mai mulți cli enți. Totodată înseamnă că fiecare solicitare de la client
către server este independentă de cererea anterioară [4], chiar dacă provin de la acelaș
client web. Acest lucru a dus la implementarea unor sesiuni la nivelulul aplicațiilor web prin
care se asociază clienților care acceseaz ă serverul un identificator unic (Session Id),
ducând la posibilitatea păstrării datelor de -a lungul mai multor cereri succesive ale aceluași
client. Fig. 2 Exemplu de raspuns HTTP

8
Consider că serviciile web au putut să se dezvolte și să beneficieze de tehnologiile deja
existente și dezvolate datorită îmbinării dintre aceste limite bine definite înpreună cu gradul
de personalizare a răspunsului.
2.2 Descrierea problemei

Primele aplica ții web constau în multiple pagini cu informa ții, informa ții asem ănătoare
care comunicau între ele pe baza hiperleg ăturilor, leg ături de care utilizatorul se folosea
pentru a naviga între pagini . Primul site Web a fost creat în anul 1991 și afișa informații
despre Organizația Europeană de Cercetare Nucleară (CERN), organizație în cadrul căreia
s-a dezvoltat Web -ul prin intermediul lui Tim Berners -Lee. [5] Un studiu f ăcut de Matthew
Gray in carul MIT arat ă că la sfârșitul anului 1993 erau raportate 623 de s ite-uri și că la
sfârșitul anului 1994 num ărul dep ășea 10,000 de site -uri. [6] Creșterea numarului de site –
uri devinde exponen țială in anii urmatori.
Această creștere a web -ului a dus și la o creștere a complexității site -urilor. Site -urile
inițiale cu informații statice au început să interacționeze cu informații introduce de utilizatori,
au introduce conturi pentru utilizatori care le permitea să modifice conținutul și chiar să il
adapteze în funcție de utilizator și setările/personalizările acestuia.
Tot odată cu intrarea în era interconectivității în care comunicarea la distanță și
informare a în timp real devin necesare și cruciale, dezvoltatori realizează că standardele
actuale ale industriei nu pot să se mapeze pe noile cereri ale spațiului web.
Dacă primele site -uri conțineau informații științifice sau academică, odată cu
dinamizarea conți nutului și popularizarea web -ului duc la deschiderea unor noi posibilități
pentru aplicațiile web atât pentru utilizatori cât și pentru dezvoltatori.
Astfel, dezvoltatori își setează noi țeluri și făcând aplicațiile mai complexe urmărind să
rezolve cât mai multe probleme din viața de zi cu zi. Încep să fie la modă aplicațiile care
rezolvă o gamă cât mai largă de probleme și care oferă cât mai multe funcționalități făcând
ca utilizatorii să nu fie nevoiți să părăsescă platforma.
Un exemplu extrem de cunoscut pe care îl putem oferi este platforma Facebook . Scopul
inițial a fost de a oferi utilizatorilor posibilitatea de a se conecta cu alți oameni din întreaga
lume . Deși o idee inedita la început, pentru a putea răspunde cereri pieței dez voltatorii
platformei au fost nevoiți să ofere și alte funcționalități precum jocuri video, posibilitatea de

9
a fi la current cu noutățile și știrile sau chiar de promovare al unor produse sau servicii.
Aceste funcționalități rezolvă probleme din viața cotidiană însă nu au făcut parte din idea
inițială. Tot odată aceste funcționalități fiind diferite din punct de vedere al activității oferite
nu pot fi scrise în acelaș limbaj de programare și poate nici chiar de aceași echipă de
dezvolatori fiind nevoie de tehnologii multiple din arii diferite.
Deducem astfel că unul din factorii care au condus către dezvoltarea și folosirea pe
scară largă a serviciilor web este creșterea complexității aplicațiilor . Funcționalitățile
importante au trebuit despărțite în aplicații de sine stătătoare care să fie mai apoi aduse în
fața utilizatorului ca o singură platformă.
Un alt pas important care a contribuit la dezvoltarea serviciilor web a fost apariția
smartphone -ului. Accesarea paginilor web de către telefoane a fost un process greu și
anevoios la început deoarece acestea erau create pentru computer, dispozitive cu rezoluții
mult mai mari decât telefoanele din perioada respectivă. Dezvoltatorii nu erau interesați de
optimizări pentru serviciile web pe telefon neexistând prea mulți utiliz atori. Așadar toate
optimizările site -ului web erau făcute de către browser și nu de cătredezvoltator. Browser -ul
filtra conținutul HTML(Hypertext Markup Language) și afișa doar conținutul important, astfel
că paginile web arătau diferit față de browser -ul de pe computer, chiar și de la un browser
de telefon la altul. Existau browsere care nu puteau rula tehnologii precum JavaScript sau
Flash care erau folosite pentru a face aplicatiile mai interective de aceea browsere -ul mobil
devenind nefolosibil de catr e utilizatori.
Odat ă cu apariția smartphene -ului aceste lucruri se schimbă. Dacă cu primele telefoane
se puteau face doar apeluri , adică comunicare la distanță prin intermediul undelor radio și
erau foarte mari ca și dimensiuni, odată cu apariția smartphon e-ului funcționalitățile
telefoanelor se schimbă, chiar și dimensiunea lor scăzând. Deși odată cu evoluția
tehnologiei acestea devin tot mai mari, cu ecrane tot mai mari, însă se pastrează o greutate
mica și portabilitate cât mai ușoară. Aceste noi telefo ane, numite smartphone, sunt folosite
nu doar pentru comunicare audio ci și pentru comunicare în timp real datorită internetului,
pentru accesarea serviciilor web, pentru navigare folosindu -se de GPS și locație.
Smartphone -urile introduce odată cu apariția lor și sisteme de operare mai puternice și
mai asemănătoare cu cele de pe computer decât telefoanele anterioare. Cele mai
cunoscute sisteme de operare sunt Android, sistem dezvoltat de către Google și folosit de

10
către majoritatea smartphone -urilor (86.2%) , iOS, system dedzvolat de Apple și folosit doar
pe dispozitivele create de ei, precum iPhone, iPad (13.7%) , și Windows Phone, s istem
dezvoltat de către Microsoft și de asemenea folosit doar pe dispozitivele create de ei
(0.1%) . [7]
Toate aceste inovații conduc la o popularizare globală a smartphone -urilor, astfel
numarul de utilizatori crescând rapid. După cum arată o statictică, numarul de utilizatori a
crescut cu aproape un miliard din 2014 până în 2018 și se asteaptă sa crească până la
2.87 d e miliarde până in 2020 . [8]

Cu această piață nou create apar și posibilitățile de inovație și extindere astfel fiecare
dezvoltator de sisteme de operare pentru telefoane dezvoltă câte un browser nou, mai
performant decât cele anterieore. Acestea seaman extrem de mult și au câte un
correspondent utilizabil pe computer. Astfel avem Google Chrome pentru Android, cât și
Fig. 3 Numărul utilizatorilor smartphone -urilor în perioada 2014 -2020 (în miliarde) [8]

11
pentru Windows, Linux și OSX, Safari pentru iOS și OSX, Internet Explorer atât pentru
Windows cât și pentru Windows Phone.
Se observă astfel o creștere a procentului de tr afic generat de dispozitivele mobile
acces ând serviciile web de la 0.7% în anul 2009 la 52.2% în anul 2018. [9] Traficul de
internet folosit de telefoanele mobile a avut și el o creștere important intre anii 2014 și
2018. [10]

Fig. 4 Utilizarea internetului de telefonie mobilă 2014 2019 [10]
Fig. 5 Procentajul paginilor web accesate telefoanelor mobile din 2009 2018 [9]

12
Un al treilea pas care a contribuit la dezvoltarea serviciilor web a fost cre șterea traficului
în web conumat de catre utilizatori de pe telefoanele mobile. Dacă inițial dezvoltatorii nu au
făcut eforturi ca aplicațiile să fie ușor folosibile dintr -un browser de pe un dispozitiv mobil,
odată cu creșterea traficului acest lucru s -a schimbat. Se naște astfel conceptul de
responsive, concept ce înseamnă că pagina web este optimizată pentru browserele
existente pe dispozitivele mobile, care cu toate că e posibil să arate diferit față de computer
va putea oferi aceleași functionalități.
De alungul timpului au existat mai multe soluții pe care dezvoltatori le -au folosit. În
subcapitolul următor voi discuta despre cât eva astfel de soluții comparându -le pentru a
vedea avantajele și dezavantajele acestora.

2.3 Servicii Web RPC, SOAP și REST

După cum am mai menționat , serviciile web apar ca o soluție la necesitatea costruiri
unui spațiu de comunicare între mașinile interconectate. O primă abordare este aceea de a
apela la un mecanism care permite apelarea unor operații menite să fie executate la
distanță . [3] Această soluție este oferită de modelul RPC (Remote Procedure Call) descris
pe scurt în secțiunea următoare.

2.3.1 RPC (Remote Procedure Call)

Este un mecanism vechi apărut cu două decenii în urmă și este folosit în construcția de
aplicații de tip client/server care se află în spații de adresă diferite [3]. Acestea sunt scrise
de către programator fără ca acesta să scrie detaliile interacțiunii și modul în care se face
trasportul datelor, acestea fiind ascunse de interfața stub care implementează protocolul
RPC [3]. Clien tul și serverul comunică prin schimb de mesaje care au un format bine
stabilit. Formatul datelor losit de RPC este XDR (External Data Representation) [3].
Stub-urile sunt cele responsabile de traslatarea datelor în și din ac est format [3].
Odată cu apariția abordării modelului de OOP (O riented Object Programming ) RPC
devine RMI (Remote Method Invokation). Spre exemplu arhitectura Java pune la dispoziție
protocolul RMI, iar .NET oferă .NET Remoting, protocoale oferite pentru a se ocupa de
trasferul datelor [3].

13
Avantajele modelului RPC
• Se pot folosi acealeași modele de date atât în client cât și în server
• Metodele care sunt apelate se apelează în mod natural c a și cum ar fi o metodă
locală [3]
• Simplificarea programelor de client și server datorită interfețelor stub care ascund
procedurilor de rețea [3]
• Marește gradul de portabilitate a aplicațiilor [3]
Dezavantajele modelului RPC
• Există multe implementări ale protocolului care nu sunt compatibile între ele
datorită unor diferențe subtile [3]
• Aceste implementări ale protocolului obligă aplicațiile client și server să fie scrise
în același limbaj de programare
• Cu cât complexitatea aplicației este mai mare, protocolul RPC este tot mai greu
de extins și intreținut.

2.3.2 SOAP (Simple Object Access Protocol)

La fel ca și RPC, SOAP este un protocol pentru trasmiterea mesajelor între două
mașini, mesaje structurate cu ajutorul formatului XML ( Extensible Markup Language) .
XML (Extensible Markup Language)
XML este un limbaj de marcare care definește un set de reguli pentru codificarea
documentelor într-un format care este ușor de interpretat atât de oameni cât și de
computere [3]. Putem considera XML ca fiind un standard internațional de descriere a
datelor/resurselor electronice [3]. Termenul de marcaj (markup) era folosit, înaintea
apariției XML, pentru a descrie anumite adnotări, găsite de obicei ca note marginale în
cadrul textelor [3]. Aceste marcaje aveau ca scop oferirea de indicații pentru un anumit bloc
de text, ca spre exemplu formatarea acestuia, cum ar trebui acest bloc să fie listat sau
chiar dacă blocul trebuie sau nu să apară în documentul final [3].
Un document XML poate con ține următoarele categorii de componente: declarația,
elementele, atributele, entitățile, secțiunile de marcare și intrucțiunile de procesare [3].
Fișierele XML pot să inceapă cu o declarație care specific a versiunea si tipul de codificare
a caracterelor [2], un exemplu de o astfel de declaratie ar fi:

14
<?xml version="1.0" encoding="UTF -8" ?> [3]
Elementul este componenta structurală a fișierului XML, acestea fiind specificate ex plicit
prin intermediul marcajelor (tag -urilor) [3]. Atributul este utilizat cu scopul de a descrie o
anumită proprietate a unui element [3]. Instrucțiunile de procesare reprezintă un tip special
de marcaj care conține informații privitoare la anumite aplicații ce urmează a fi e xcutate
pentru procesarea conținutului [3].

Anumite părți ale documentului necesită un tratament special în ceea ce privește modul
de procesare, există deci posibilitatea folosirii secțiunii CDATA (character data), cu rolul de
inhibare a prelucrări construcțiilor XML [3].

Fig. 6 Exemplu de fi șier XML [3]

15

Protocolul SOAP encapsulează informațiile într -un plic (envelope) care este format din
două elemente, antent (header) și corp (body) [3]. Antetul conține infromații cu privier la
modul cum va fi procesat mesajul de către server, precum informații despre autentificare,
autorizare, loccația destinatarului și a emitentului și este optional acesta putând să
lipsească [3]. Corpul stochează mesajul care este trimis și va fi procesat exprimat cu
ajutorul sintaxei XML [3]. Deoarece acelaș mesaj poate fi scris sub mai multe forme în
XML, datele descries trebuie să urmeze o structură stabilită, a ltfel procesarea nu este
posibilă de către server, însă dacă aceasta este respectată nu avem alte restricții cu privire
la datele ce pot fi trasmise decât să fie formatate ca XML [3].
O aplicație SOAP este formată din noduri (en tități de calcul intermediare) care schimbă
mesaje între ele. Mesajele SOAP pot trece printr -un număr oarecare de noduri
intermediare până ajung la destinatarul final. Specificațiile SOAP presupun existența unor
noduri intermediare care descriu comportamen tul unui nod în anumite circumstanțe,
acestea primesc mesajul și îl pot altera sau nu. [3]

Avantajele protocolului SOAP
• Datorită faptului că folosește HTTP nu este nevoie de configurări adiționale de proxy
pe partea de server [3], spre deosebire de RPC
• Protocolul este independent de limbaj, astfel fiind posibilă comunicarea intre aplicații
scrise in limbaje diferite [3]
• Poate codifica orice fel de date sau informații cât timp se respectă structura aleasă
și intrucțiunile
• Ușor de citit datorită XML -ului
Fig. 7 Exemplu de folosire CDATA în XML [3]

16
• Are propriul standard de securitate care este extrem de sigur
Dezavantajele protocolului SOAP
• Dacă considerăm un set de date considerabile atunci mesajul devine foarte mare,
astfel că lungimea de bandă folosită este și ea mare lu cru care ar putea deveni o
problem ă
• Mesajele sunt procesate greu datorită descriptivității

2.3.3 REST (Representational State Transfer)
În anul 2000 , Roy Fielding descrie în teza sa de doctorat regulile și intrucțiunile pe care
o aplicație trebuie să o urmeze c a să fie RESTful. REST este o arhitectură care expune
informații despre aplicație sub forma resurselor manipulate și îi oferă clientului posibilitatea
de a manipula resursele existente sau de a creea altele noi.
Fielding propune că arhitectura Web -ului este determinată de constrângerile care se
impun asupra elementelor componente și explică faptul că proprietățile oferite de aceste
constrângeri reflect conceptul de stil arhitectural [11]. Astfel că, dacă se aplică co nstrângeri
suplimentare Web -ului, putem ajunge la un nou stil arhitectural care să reflecte o
arhitectură modernă, mai aproape de nevoile dezvoltatorilor [11].
Astfel REST este format din constrângeri preluate din Web și câteva aduse în plus.
REST este proiectat s ă fie simplu și vizibil, adică fiecare aspect al acestuia trebuie să
fie auto -descriptiv și să urmeze principiile preluate din HTTP și anume că manipularea
datelor se face cu verbele HTTP, resursele pot avea reprezentări multiple și caracterul
stateless [12].
Constrângerile preluate din Web de Fielding sunt:
a. Prima constrângere este legată de stilul architectural client -server, adică principiul
separării responsabilităților. Separarea permite ca cele două componente să
evolueze independent [11]
b. Constrângerea că la nivelul comunicări i Web -ul se folosește de un model de
comunicare stateless, adică nu se salvează nici o stare, serverul neavând
informații despre clientul care face cererea iar răspunsul conține informațiile
complete [11]

17
c. Constrângerea cache care îmbunătățește eficiența. Aceasta oferă posibilitatea
clientului de servi o resursă dintr -un mediu de stocare propriu, dacă acesta a mai
interacționat cu resursa respective scăpându -se deci de unele interecțiuni [11]
Constrângerile aduse în plus de Fielding sunt:
a. Interfața uniformă, comună între componente , este caracteristica principală.
Aceasta simplifică arhitectura general a sistemului, oferă independență
serviciului și încurajează evoluția independentă [11]
b. Arhitectura trebuie să fie compusă din straturi ierarhice. Aceasta face ca un nivel
al aplicației să interacționeze cu nivelul imediat următor înbunatățind
scalabilitatea sistemului [11]
c. Ultima constrânge re vizează stilul de proiectare al aplicațiilor code -on-demand și
este o constrângere opțională [11]
Astfel REST este un model arhitectural care să servește drept un cadru premergător
pentru un spațiu Web standardizat în care comunicarea dintre două mașini să se efectueze
într-un mod eficient. REST folosește protocoalele și conceptele mature din Web, ca HTTP
și URI, cache și metode de securizare a datelor trimise [11].
REST es te o abstractizare a elementelor arhitecturale dintr -un sistem hipermedia
distribuit [11]. Acesta ignoră detaliile implementării componentelor și ale sintaxei
protocolului pentru a se concentra asupra rolurilor componentelor, constrângerilor asupra
interacțiunii acestora cu alte componente și interpretării lor a elementelor importante de
date. REST -ul cuprinde constrângerile fundamentale asupra componentelor, conectorilor și
datelor care definesc baza arhitecturi i Web și, prin urmare, esența comportamentului său
ca aplicație bazată pe rețea [11].
REST oferă un set de constrângeri arhitecturale care, atunci când sunt aplicate ca un
întreg, subliniază scalabilitatea interacțiunilor compo nentelor, generalizarea interfețelor,
implementarea independentă a componentelor și componentele intermediare pentru a
reduce latența interacțiunii, a impune securitatea și a încorpora sistemele vechi [11].
Avantajele REST:
• Lungimea de bandă folosită este mai mica decât la protocolul SOAP deoarece
mesajele sunt mai simple

18
• REST folosește concepte familiare pentru interacțiuni, adică se folosesc
concepte deja existente în Web care doar sunt extinse sau adaptate [11]
• Integritatea datelor transmise sau securitatea lor este garantată de tehnologii
existente, bine cunoscute [11]
• Comunic area în REST se face mai ușor decât în SOAP, deoarece interacțiunea
și logica care se aplică unei resurse este definită de URI, operația simplificându –
se la metoda de acces HTTP ca: GET, POST, PUT, DELETE etc.. [11]
• REST este indepe ndent de limbaj ul de programare
Dezavantajele REST:
• REST are un character general și oferă restricții sistemelor astfel implică o
complexitate mai mare ce trebuie luată în considerare atunci când se dezvoltă aplicația
• Odată cu moștenirea proprietățiilo r și a tehnologiilor benefice din Web, se
moștenesc și neajunsurile și problemele [11]

După cum se poate observa din avantajele și dezavantajele celor trei protocoale
descrise în acest capitol, protocolul REST este cel mai avantajos. Folosirea protocolului
HTTP pentru comunicare îl fac ușor de folosit. Acestea sunt și motivele pentru care am
ales folosirea serviciilor Web REST pentru aplicația server implementată.

19
3. Tehnologii folosite

Am împarțit t ehnologiile folosite în două categorii după aplicația în care s -au folosit,
adică tehnologii pentru: aplicația client și pentru aplicația server. În acest capitol vom
include și detalii de configurare pentru fiecare dintre aplicații. Aplicația server este un
serviciu Web REST dezvoltat folosind design pattern -ul MVC (Model View Controller) care
expune resurse pe care aplicația client, o pagină web , le poate manipula și prezenta
utilizatorilor.
Aceste două aplicații sunt complentare și împreună form ează aplicația EasyParking.
MVC (Model View Controller)
MVC (Model View Controller) este un stil arhitectural care împarte aplicația în trei părți
interconectate, separând astfel reprezentarea informației pe care utilizatorul o primește și
pe care utilizatorul o oferă aplicației ca da te de intrare, față de reprezentarea internă pe
care această informație o are în logica aplicației.
Componentele MVC sunt:
• Modelul corespunde logicii aplicației care se ocupă cu manipularea datelor având
ca resposabilități acțiuni și operații care se aplic ă pe datele respective și
eventuala omunicare și stocare a acestor date într -un sistem de stocare ca baza
de date
• View -ul prezintă datele utilizatorului. O vizualizare poate fi orice reprezentare de
ieșire: o pagină HTML, o diagramă, un tabel sau chiar o i eșire text simplă. O
vizualizare nu ar trebui să -și apeleze niciodată propriile metode; numai un
controler ar trebui să o facă. Este de asemenea modalitatea de interacțiune a
utilizatorului cu aplicația
• Controller -ul este un liant între componentele Model și View care procesează
datele care trebuie expuse pe View și pregătește datele ce trebuie procesate de
către model.
Deoarece cele trei sunt decuplate, fiecare din ele pot fi extinse, modifica sau înlocui fără
a fi nevoie să fie rescrise celelalte două.

20
3.1 Tehnologii folosite pentru aplicația server

Aplica ția server este un serviciu Web REST. Este scrisă în limbajul de programare
Python cu ajutorul frameworkurilor Flask și SQLAlchemy. Cu ajutorul acestora reușește să
adapteze paradigma REST respectând cons trângerile impuse de Fielding. Datele trimise
sunt formatate cu ajutorul formatului JSON fiind ușor de interpretat atât de către server cât
și de către client, care este o aplicație scrisă cu React.

JSON (JavaScript Object Notation)
JSON (JavaScript Objec t Notation) este un format ușor de interschimbare a datelor.
Este ușor de citit și scris pentru oameni. Este ușor de parsat și generat de către mașini.
JSON este un format text care este complet independent de limbaj dar folosește convenții
care le sunt fa miliare programatorilor familiei de limbaje C, care include C, C++, C#, Java,
JavaScript, Perl, Python, și multe altele. Aceste proprietăți fac din JSON un limbaj ideal
pentru interschimbarea datelor. [13]
JSON este construit pe două structuri:
• O colecție de perechi nume/valoare. În diverse limbaje aceasta este realizată ca
un obiect , o înregistrare, o structură, un dicționar, o tabelă hash, o listă de chei, sau un
tablou asociativ. [13]
• O listă ordonată de valori. În cele mai multe limbaje, aceasta este realizată ca
un tablou , un vector, o listă, sau un șir. [13]
Acestea sunt structuri de date universale. Aproape toate limbajele de programare
moderne le suportă într-o formă sau alta. Are sens ca un format de date care este
interschimbabil cu limbajele de programare să fie bazat tot pe aceste structuri. [13]
În JSON, acestea iau una dintre următoarele forme:
Un obiect este o mulțime n eordonată de perechi nume/valoare. Un obiect începe
cu { (acoladă deschisă) și se termină cu } (acoladă închisă). Fiecare nume este urmat
de : (două puncte) și perechile nume/valoare sunt separate de , (virgulă). [13]

21
Un tablou este o colecție ordonată de valori. Un tablou începe cu [ (paranteză dreaptă
deschisă) și se termină cu ] (paranteză dreaptă închisă). Valorile sunt separate
cu , (virgulă). [13]
O valoare poate fi un șir în ghilimele, sau un număr , sau true sau false sau null, sau
un obiect sau un tablou . Aceste structuri pot fi imbricate. [13]
Un șir este o secvență de zero sau mai multe caractere Unicode, plasate între ghilimele,
și folosind secvențe escape cu backslash . Un caracter este reprezentat ca un șir cu un
singur caracter. Un șir seamănă foarte mult cu un șir din C sau Java. [13]
Un număr seamănă foarte mult cu un număr din C sau Java, cu excepția că formatele
octal și hexa zecimal nu sunt folosite. [13]
Spațiile albe pot fi inserate între orice pereche de atomi lexicali. Exceptând câteva
detalii de encoding asta descrie complet limbajul. [13]

3.1.1 Flask

Flask este un micro framework pentru dezvoltarea web în Python [14]. Un framework
este o bibliotecă care urmărește să re zolve o parte dintr -o problem generică, de exemplu
când dezvolăm aplicații web trebuie să rezolvăm probleme precum rutarea de la URL -uri la
resurse, inserarea datelor dinamice în HTML și interacțiunea cu utilizatorul final [14].
Flask este un micro framewo rk deoarece implementează n u mai funcționalități de bază
și lasă func țiile avansate la extensii [14]. A început ca o glumă în luna Aprilie dar a devenit
foarte repede popular. [15] Acum este des utilizat pentru start -up-uri și devine tot mai
Fig. 8 Exemplu de mesaj JSON [13]

22
acceptat ca și instrument pentru soluții rapide și simple fiind ușor de utilizat,flexibil în
configurarea aplicațiilor [15].
Acesta oferă un set de biblioteci pentr u a gestiona diverse sarcini:
• Maparea adreselor URL
• Gestiunea sesiunilor și securizarea cookie -urilor
• Manipularea flexibilă a răspunsurilor
• Interogarea parolelor
Flask este construit pe baza Werkzeug și Jinja2. Acesta profit de caracteriticile unice
ale lui Jinja2 [16]. Clasa Flask este utilizată pentru a crea o instanță a unei cereri WSGI și
odată ce avem un obiect de acest tip putem folosi metodele și decoratoarele spacifice
Flask [16]. Decorator ‘route’ este utilizat pentru a conecta o funcție de vizualizare cu o
adresă URL [16]. În exemplul de mai jos, URL -ul este rădăcina de bază a site -ului, iar cee
ace vom vizualiza în pagina web este un simplu șir de caractere [15].

Poate exista necesitatea unor resurse prezentate pe baza unor solicitări precum
conexiunea la o bază de date [15]. Flask oferă diferite decoratoare pentru a seta aceste
lucruri cu ușurintă [15]. În exemplul de mai jos, presupunem că metoda ‘connect_ db’ este
definită în altă parte și are grijă să se conecteze la o bază de date deja inițializată. Orice
funcție decorate cu ‘before_request ’ va fi apelată înaintea unei cereri și vom folosi acel apel
pentru a stoca conexiunea bazei de date în obiectul special furnizat de Flask [15]. Pentru a
ne asigura că conexiunea este închisă la sfârșitul cererii, putem folosi decoratorul
‘teardown_request ’ [15]. Funcțiile decorate cu acest lucru sunt garantate pentru a fi
executate chiar dacă se produce o excepție [15]. De fapt, dacă se întâmplă acest lucru, Fig. 8 Exemplu de aplicație folosind Flask

23
excepția este transmisă [15]. Există, de asemenea, un decorator ‘after_request ’, care se
numește cu răspunsul ca parametru și trebuie să returneze acel sau alt obiect de răspuns
[16].

În acest exemplu încercăm doar să obținem conexiunea și, dacă există, să o închidem
fără a ne interesa dacă există orice fel de excepție.
Obiectul ‘session’ permite să stochezi informații specific unui utilizator de la o cerere la
alta[15]. Aceste sesiuni sunt implementate folosind cookie -uri securizate, de ceea au
nevoie de o cheie ca s ă poate fi utilizate[15]. Astfel putem să căuăm un username în
sesiunea existentă și să ii verifice starea de conectare corespunzătoare, adică dacă este
sau nu conectat, după cum se poate observa in metoda index() din exemplu de mai jos.
Elementele din ses sion pot fi setate , dacă informațiile sunt transmise cu metoda POST,
sau doar verificate dacă acestea sunt trasmise cu metoda GET. În figura următoare aest
lucru se poate observa la metoda login(), unde dacă trasmitem cu POST se salvează
datele in sessio n, dacă nu se afisează pagina de login. Aceste sesiuni pot fi șterse, de
exemplu când se face logout.

Fig. 9 Exenplu de conexiuni la cerere [16]

24

În concluzie, Flask poate fi folosit pentru a scrie diferite tipuri de aplicații, dar datorită
disegn -ului său este ma bun pentru aplicați de dimensiuni mici spre medii. În mod special
este bun pentru web APIs și servicii. Nucleul său mic îi permite să fie folosit pentru
backend și este extrem de compatibil cu SQLAlchemy atunci când avem de manipulat baze
de date într -o apliacție web.

3.1.2 SQLAlchemy

Odată cu apariția aplicațiilor Web moderne, bazele de date relaționale devin
fundamentul pe care orice aplicație Web se construiește. Modelul de date care este ales
din timp afectează aproape fiecare aspect al codului care urmează. SQLAlchemy este un Fig. 10 Exemplu de folosire session [16]

25
ORM ( Object Relational Mapping ) foarte puternic care permite să lucrăm cu baza de date
direct din interiorul Python fără a mai fi nevoie de alte sisteme complexe pentru baza de
date. [15]

ORM (Object Relational Mapping)
ORM este o bibliotecă care automatizează trasferul datolor stocate in tabelele bazelor
de date în obiecte care apa r și sunt folosite în codul aplicației [17].

Acestea, ORM -urile, furnizeză o abstractizare la nivel înalt pe o bază de date relațională
care permite unui dezvoltator să scrie cod într -un limbaj de programare, în cazul meu în
Python, în loc de SQL pentru a efectua operații CRUD (Create Read Update Del ete) pe
datele și schemele din baza de date [17]. ORM -ul face posibilă schimbarea unei aplicații
între diferite baze de date relaționale cu modificări minime ale codului [17]. Desigur că are
și numero ase dezavantaje precum:
• Nepotrivire a impedanței , adică modul în care programatorul utilizează obiectele
este diferit de modul în care datele sunt stocate și integrate în baza de date
• Potențial de performanță redusă
• Trasformarea complexității din bazza de date în codul aplicației
După cum am mai men ționat, SQLAlchemy oferă o interfață generalizată pentru crearea
și executarea unui cod de bază de date fără a fi nevoie de instrucțiuni SQL. Este compus
din două componente, Core și ORM. SQLALchemy Core include interacțiunea Python
Database API (DBAPI), redarea unor declarații SQL textuale înțelese de baza de date și
Fig. 11 Exemplu de cum sunt convertite datele folosind ORM [17]

26
gestionarea schemelor fiind prezentate ca API -uri publice [18]. Acesta poate fi utilizat cu
sau fără funcț iile ORM [17]. ORM este apoi o bibliotecă specifică , după cum a fost descris
mai sus, construită pe partea de sus a Core [18].
Erorile ce țin de bazele de date sunt mai puțin frecvente deoarece eorile de sintaxă sunt
verificate de interpretorul Python, iar SQLAlchemy are propriul lui nivel de verificare al
erorilor și un API foarte bine definit [15]. SQLALchemy poate, de asemenea, să ajute la
evitarea vulnerabilității SQL injection, să ofere o mulțime de biblioteci utile care pot
funcționa direct cu modelele SQLAlchemy pentru a oferi lucruri precum interfețele de
întreținere și API -urile RESTful [15].
SQLAlchemy consideră că dezvoltatorul trebuie să fie dispus să ia în considerare forma
relațională a datelor sale [18]. Un sistem care predetermină și ascunde deciziile de
proiectare și interogare marchează utilitatea utilizării unei baze de date relaționale,
conducând la toate problemele clasice de nepotrivire a impedanței [18]. În același timp,
punerea în aplicare a acestor decizii poate și ar trebui să fie executată pe cât posibil cu
ajutorul unor modele de nivel înalt [18]. Legarea unui model de obiect la o schemă și
persistența acesteia prin interogări SQL este o sarcină foarte repetitivă [18]. Permiterea
instrumentelor pentru automatizarea acestor activități permite dezvoltarea unei aplicații mai
succintă, mai capabilă și mai eficientă și poate fi creată într -o fracțiune din timpul necesar
pentru a dezvolta ma nual aceste operații [18].
Expunând concepte relaționale, SQLAlchemy îmbrățișează ideea de " leaky
abstraction ", încurajând dezvoltatorul să adapteze un strat de interacțiune personalizat, dar
complet automatizat între aplicație și baza de date relațională [18]. Inovația SQLAlchemy
este măsura în care permite un grad ridicat de automatizare, cu puțin sau deloc sacrificare
în controlul asupra bazei de date relaționale [18].
Această separere Core -ORM este caracteristica cea mai definită a SQLAlchemy -ului și
are atât argumente pro cât și contra [18]. Core explicită prezentă în SQLAlchemy conduce
ORM să asocieze atributele clasei bazate pe baze de date unei structuri cunoscute ca

27
Table mai degrabă decât direct pe numele coloanelor lor de șir [18]. Dezavantajul abordării
ORM / Core este că instrucțiunile trebuie să parcurgă mai mulți pași [18].

Utilizarea modernă a centrelor SQLAlchemy în jurul extensiei Declarative, care este un
sistem de configurare care seamănă cu sistemul comun de declarații de clasă, similar cu
înregistrările active, utilizat de multe alte instrumente de relaționare obiect [18]. În acest
sistem, utilizatorul final definește în mod explicit atributele în linie cu definiția clasei, fiecare
reprezentând un atribut din clasa care urmează să fie mapată [18]. Obiectul Table , în
majoritatea cazurilor, nu este menționat în mod explicit, și nici nu este funcția mapper ,
numai clasele, obiectele Column și alte atribute legate de ORM sunt numite [18].
Extensia Declarative utilizează o metaclasă Python, care este o modalitate la îndemână
de a executa o serie de operații de fi ecare dată când o clasă este declarată pentru prima
dată, pentru a genera un obiect Table nou din ceea ce a fost declarat și pentru al trece
la funcția mapper împreună cu clasa [18]. Funcția mapper își face apoi treaba exact în
același mod, repartizând propriile atribute pe clasă și înlocuind ceea ce a existat anterior
Fig. 12 Diagrama stratificării SQLAlchemy

28
[18]. Până la finalizarea inițializării metaclasei (adică atunci când fluxul de execuție
părăsește blocul delimitat de clasa curentă, în exemplul de mai jos de User ), obiectul
Column marcat de acest e variabile, după cumse poate observa în exemplul din figura
urmatoare, id, username, email și password au fost mutat e într-un nou tabel , și User.id ,
User. username, User. email și User .password au fost înlocuit e de un noi atribut e specific e
mapării.

Aceste atribute care au fost atașate clasei User sunt obiecte cunoscute în Phyton ca
descriptor, obiecte care au metodele __get__, __set__și __del__ [18].
Relantionship definește o referință la o clasă asociată. Un obiect relations hip unește
două obiecte Mapper , în general, un Mapper este considerat a fi dependent de celălalt,
deoarece relationship presupune că un Mapper are o dependență de chei străine față de
cealaltă [18]. Acestea definesc relații one -to-many sau many -to-one, dar există reguli
asemănătoare ce pot defini și relațiile many -to-many.
SQLAlchemy inițiază toate comportamentele de încărcare obiect prin intermediul unui
obiect numit Query. Starea de bază Query începe cu include rea entitățil or , care este lista
de clase mapate și / sau expresii SQL individuale care urmează să fie interogate [18]. De
asemenea, are o referință la Session, care reprezintă conectivitatea la una sau mai multe
baze de date, precum și o memorie cache a datelor care au fost acumulate în legătură cu
tranzacțiile efectuate pe acele conexiuni [18].
Un câmp Query va genera instanțe de clasa pe care se realizează interogarea , în raport
cu un nou Session creat. Query furnizează un model generativ de constructor în același
mod ca și structura select, în care criterii suplimentare și modificatori sunt asociate cu o
instrucțiune care construiește o singură metodă de apel la un moment dat [18]. Atunci când
Fig 13 Exemplu de mapare în aplicație

29
se solicită o operație iterativă Query, ea construiește o construcție de expresie SQL
reprezentând un SELECT, îl emite în baza de date și apoi interpretează rândurile setului de
rezultate ca rezultate ORM orientate corespunzând setului inițial de entități solicitate [18].
În SQLAlchemy, obiectul Session prezintă interfața publică pentru utilizarea reală a
ORM , adică încărcarea și persistența datelor. Acesta oferă punctul de plec are pentru
interogări și operații de persistență pentru o conexiune de date dată [18]. Session p e lângă
faptul că servește drept gateway pentru conectivitatea bazei de date, acesta menține o
referință activă la setul de entităț i mapate care sunt prezente în memorie în raport cu
această sesiune [18].
Metoda flush furnizată de Session transformă peste activitatea sa la un modul separat
numit unitofwork [18]. Procesul de flush este probabil cea mai complexă funcție a
SQLAlchemy. Treaba modului unitofwork este de a muta tot ce se află în stare de așteptare
prezente într -o anumită sesiune la baza de date, golirea colectțiile new, dirty
și deleted menținute de Sess ion [18].
SQLAlchemy a urmărit foarte mult de la începuturile sale, cu scopul de a fi cel mai
bogat și mult mai versatil produs de baze de date posibil. Acest lucru sa realizat în timp ce
menținerea accentului pus pe bazele de date relaționale, recunoscând faptul că susținerea
utilității bazelor de date relaționale într -o manieră profundă și cuprinzătoare este o
întreprindere majoră; și chiar și acum, domeniul de aplicare al angajamentului continuă să
se dezvăluie ca fiind mai m are decât a fost perceput anterior. [18]
SQLAlchemy poate fi folosit singur împreună cu Flask, sau se poate folosi extensia
dezvoltată de creatorul Flask -ului, anume Flask -SQLAlchemy. Flask -SQLAlchemy este o
exxtensie pentru Flask care adaugă supoprt pentru SQLAlchemy și care are scopul de a
simplifica utilizarea celor două framework -uri împreună prin furnizarea de aju tor
suplimentar care face mai ușor de împlinit sarcinile comune.
3.2 Tehnologi folosite pentru aplicația client

Aplicația client este o aplicație web dezvoltată cu ajutorul bibliotecii React care folose ște
limbajul JavaScript.
Aplicația încearcă să fie cât mai user friendly, atât în ceea ce privește afișarea pagini,
să fie re sponsive pe orice telefon dar și pe desktop, dar și să fie ușor de folosit și înțeles,
cu feedback -uri cât mai relevante.

30
3.2.1 React
Conform descrieri oficiale, React este o librărie JavaScript pentru a construi interfețe
pentru utilizatori. A fost dezvoltat de către Facebook, și este menținută de către aceștia și
de o comunitate de dezvoltatori și companii individuale. [19] A apărunt în anul 2013. React
oferă componenta View a arhitecturii MCV descrisă anterior în acest capitol.
Conceptul principal din React sunt Componentele, structuri unitare ce încapsulează atât
logică cât și o parte de prezentare pentru utilizator pentru o anumită funcționalitate sau
chiar pentru o parte componentă a unei funcționalități. Aceste componente pot fi
funcționale, adică partea de logică și prezentare a componentei este încapsulată într -o
funcție, sau componenta poate fi reprezentată de o clasă în care partea de prezentare
poate fi scrisă cu ajutorul JSX (Javascript XML). JSX este o extensie a sintaxei limbajului
JavaScript. JSX oferă la fel ca HTML -ul o medoalitate de a structura redarea componetelor
folosind sintaxa familiară a JaxaScript -ului. [19]
Un concept important care există pentru componentele din React este starea (state)
care este o multitudine de atribute ce descriu comportamentul componentei la un moment
în timp. Setarea atributelor stării se face cu met oda this.setState care face ca o omponentă
să trebuiască să fie redesenată, fiindu -i astfel reapelată metoda render(). [19]
Un exemplu de sintaxa de setare a starii in React:

Fig. 14 Exemplu de clasă în React

31

În figura anterio ară la linia 16 începe declara ția clasei Register care extinde clasa
Component care ofer ă posibilitatea clasei Register să fie o componentă. La linia 17 avem
declarația stării (state -ului) care conține respectivele atribute iniția lizate, în cazulde față cu
string -uri goale sau booleane. Pe liniile 33 și 34 se poate observa setarea starii unui atribut
pe o altă valoare.
Un alt concept care există pentru componentele din React sunt proprietățile (props)
care sunt opțiunile component ei. Acestea nu trebuie să se schimbe niciodată, sunt
inmutabile. Componentele sunt responsabile pentru determinarea proprietăților copiilor
derivați din ea. Acestea sunt inițializate în acelaș fișier ca componenta în sine și definește
proprietățile pe care trebuie să le aștepte componenta atunci când este apelată.
Principala responsabiliate a componentei este de a reda datele în HTML. Așadar props
și state reprezintă împreună datele brute generate de către HTML, astfel reprezentând
datele de intrare pentru funcția render a unei componente. [20]

3.2.2 MobX

MobX este o solu ție de management al state -ului simplă, scalabilă și intensiv testată în
aplicații. Este o bibliotecă independentă, dar cu toate acestea este extrem de utilizată
împreună cu React. [21] Cu toat e că React are propriul lui management de state, acesta
are câteva probleme: [22]
• Nu există posibilitatea de a paartaja state -ul cu alte componente
• Prea multe state -uri devin greu de menținut pe termen lung
• ‘props drilling’, adic ă dacă se trasmite state -ul de la părinte la copil, devine dificil
de gestionat toate props -urile deoarece suntem nevoiți să pasăm toate aceste
props către toate componentele care se află între parinte și copil
Toate acestea pot fi rezolvate folosind MobX. MobX face gestionarea state -ului simplă,
abordând problema principală: face imposibilă producerea unei stări inconsistente.
Conceptual , MobX tratrează aplicația ca pe o foaie de c alcul. [21]
Mai întâi de toate, există state -ul aplicației (application state) . În al doilea rând,
există derivații (derivations) , adică orice valoare care poate fi calculată automat din state -ul
aplicației. Aceste derivări sau valori calculate pot varia de la valori simple, până la lucruri

32
complexe . Reacțiile (reactions) sunt foarte asemănătoare cu derivările. Diferenț a principală
este că aceste funcții nu produc o valoare , în schimb, se execută automat pentru a efectua
anumite sarcini. Ele se asigură că DOM -ul este actualizat sau că solicitările de rețea se fac
automat la momentul potrivit. În sfârșit, există acțiuni (actions) . Acțiunile sunt toate lucrurile
care alterează state -ul. MobX se va asigura că toate modificările aduse stării aplicației
cauzate de acțiunile utilizatorului sunt prelucrate automat de toate derivările și reacțiile. [21]

MobX adaugă caracteristica Observable structurilor de date existente (cum ar fi
obiectele si vectorii). Acest lucru poate fi facut prin anotarea @observable. Folosind
această anotare ar fi echivalent cu transformarea unei pro prietati a unui obiect intr -o celula
dintr-o foaie de calcul. Se pot defini valori care vor fi derivate automat atunci când anumite
date sunt modificate. Acest lucre se face losind anotarea @compute sau folosind funcțiile
getter/setter atunci când este fol osit (extend)Observable. Reacțiile (reactions) sunt similare
cu o valoare calculată, dar în loc să producă o valoare nouă, o reacție produce un efect
secundar pentru obiecte cum ar fi tipărirea pe consolă, solicitarea rețelei, etc. Chiar și
componentele po t fi făcute să fie reactive prin folosirea anotării @observer asupra lor.

Fig. 15 Conceptul MobX

33
4. Aplicația EasyParking

Cu toate că ne afăm în era comunicării și a informației, există multe procese din viața
cotidiană pe care tehnologia încă nu le -a îmbunătățit sau în cadrul cărora există loc de
îmbunătățire. Este și cazul procesului de parcare în parcările aglomerate ale s upermaket –
urilor și a mall -urilor. Aplicația EasyParking poate fi aplicația care prezintă aceste parcări
aglomerate și afișează în timp real informații despre disponibilitatea locurilor de parcare,
unde sunt acestea, câte sunt, etc., toate acestea prin imp lementarea locurilor de parcare
automatizate și inteligente prin diferiți senzori care ar obține aceste informații din mediul
înconjurător lor.
EasyParking propune o soluție bazată pe existența unui server care are acces la aceste
informați trasmise de sen zorii existenți pe fiecare loc de parcare și afișarea lor în interfața
oferită de aplicație.

4.1 Arhitectur ă

34

4.2 Funcționalități
Aplicația întâmpină utilizatorul cu un design aimplist care să fie ușor de utilizat și înțeles
atrăgând atenția asupra acțiunilor care pot fi făcute.

1. Înregistrare
Pentru a putea utiliza aplicația utilizatorul trebuie să se înregistreze. Să furnizeze câteva
informați personale, un nume de utilizator și o parolă.

35

2. Logare
Pentru a acesa aplicația utilizatorul trebuie să se logheze. Acesta introduce emai -lul sau
username -ul creat și parola.

36

3. Harta
Pagina principală prezintă harta orașului Cluj pe care sun așezate pin -uri pentru a
identifica parcările care au acest sistem de monitorizare implementat care permite
acesarea hărții parcării respective.

37

Bibliography

[1] "Searching for Parking Costs Americans $73 Billion a Year," Inrix, 12 July 2017. [Online].
Available: http://inrix.com/press -releases/parking -pain-us/. [Accessed 2019].
[2] "What is the difference between the Web and the Internet?," W3C, [Online]. Available:
https://www.w3.org/Help/#webinternet. [Accessed April 2019].
[3] A. Lenuța, Servicii Web. Concepte și implementări, Iași: Editura Polirom, 2006.
[4] A. Grover, "Under The Hood Of HTTP!," 7 February 2018. [Onli ne]. Available:
https://codeburst.io/under -the-hood -of-http-12e50dfc126e. [Accessed 13 April 2019].
[5] "History of the World Wide Web," Wikipedia, [Online]. Available:
https://en.wikipedia.org/wiki/History_of_the_World_Wide_Web. [Accessed 15 April 2019] .
[6] "Web Growth Summary," [Online]. Available: https://www.mit.edu/people/mkgray/net/web –
growth -summary.html. [Accessed 15 April 2019].
[7] "Comparison of mobile operating systems," Wikipedia, [Online]. Available:
https://en.wikipedia.org/wiki/Compar ison_of_mobile_operating_systems. [Accessed 17 April
2019].
[8] "Number of smartphone users worldwide from 2014 to 2020 (in billions)," Statistica, June 2016.
[Online]. Available: https://www.statista.com/statistics/330695/number -of-smartphone -users –
worldwide/. [Accessed 15 April 2019].
[9] "Percentage of all global web pages served to mobile phones from 2009 to 2018," Statista, January
2018. [Online]. Available: https://www.statista.com/statistics/241462/global -mobile -phone –
website -traffic -share/. [Accessed April 2019].
[10] "Mobile phone internet user penetration worldwide from 2014 to 2019," Statista, August 2015.
[Online]. Available: https://www.statista.com/ statistics/284202/mobile -phone -internet -user-
penetration -worldwide/. [Accessed April 2019].
[11] R. T. Fielding, 2000. [Online]. Available:
https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm. [Accessed April 2019].
[12] B. Valentin, RESTful We b API Design with Node.js 10, Birmingham: Packt Publishing Ltd.,
2016.
[13] D. Crockford, "Prezentarea JSON," [Online]. Available: https://www.json.org/json -ro.html.
[Accessed April 2018].
[14] D. Gareth, A. Shalabh and S. Jack, Flask: Building Python Web Services, Birmingham: Packt
Publishing Ltd., 2017.
[15] M. Coopperwaite and C. Leifer, Learning Flask Framework, Birmingham: Packt Publishing Ltd.,
2015.
[16] C. d. l. Guardia, Phyton Web Frameworks, O’Reilly Media, Inc., 2016.
[17] M. Makai, "Full Stack Python," 2012. [Online]. Available: https://www.fullstackpython.com/.
[Accessed April 2019].

38
[18] M. Bayer, "SQLAlchemy," [Online]. Available: http://aosabook.org/en/sqlalchemy.html.
[Accessed April 2019].
[19] Wikipedia, "React (JavaScript library)," Wikipedia, [Online]. Available:
https://en.wikipedia.org/wiki/React_(JavaScript_library). [Accessed April 2019].
[20] S. Between, "React Series Part 1: Why Use React, What Is It?," Space Between, [Online].
Available: https://www.spacebetween.co.uk/blog/react -series -part-1-why-use-react -what-is-it.
[Accessed April 2019].
[21] "MobX," [Online]. Available: https://mobx.js.org/getting -started.html. [Accessed April 2019].
[22] S. Bhimani, "Getting Started with Mobx," Medium, 2 August 2018. [Online]. Available:
https://medium.com/@shoaibbhima ni1392/getting -started -with-mobx -82306df92d90. [Accessed
April 2019].