Miholca Ionela -Maria [618184]

1
UNIVERSITATEA BABEȘ -BOL YAI CLUJ -NAPOCA
FACULTATEA DE MATEMATICĂ ȘI INFORMATICĂ
SPECIALIZAREA INFORMATICĂ

LUCRARE DE LICENȚĂ
Food4You

Conducător științific:
Dr. Maria Camelia Chisăliță -Crețu, Lector Universitar

Absolvent: [anonimizat]

2020

2
Cuprins
1. Introducere ………………………….. ………………………….. ………………………….. …………………….. 4
1.1 Scurtă prezentare a aplicației ………………………….. ………………………….. ………………… 4
1.2 De ce o aplicație mobilă? ………………………….. ………………………….. ……………………….. 4
1.3 Motivarea alegerii temei ………………………….. ………………………….. ……………………….. 5
1.4 Descrierea capitolelor ………………………….. ………………………….. ………………………….. .5
2. Aplicații similare ………………………….. ………………………….. ………………………….. …………….. 7
3. Introducere in World Wide Web ………………………….. ………………………….. …………………….. 8
3.1 Ce este World Wide Web? ………………………….. ………….. Error! Bookmark not defined.
3.2 Scurt istoric al WWW ………………………….. ………………………….. ………………………….. .8
3.3 Protoc oale WWW ………………………….. ………………………….. ………………………….. …….9
3.3.1 HTTP ………………………….. ………………………….. ………………………….. ………………… 9
3.3.2 SOAP ………………………….. ………………………….. ………………………….. ……………… 10
3.3.3 SSL ………………………….. ………………………….. ………………………….. …………………. 11
3.3.4 WebSocket ………………………….. ………………………….. ………………………….. ……….. 12
4. Servicii RESTful ………………………….. ………………………….. ………………………….. …………… 13
4.1 Rest ………………………….. ………………………….. ………………………….. ………………………. 13
4.2 Client -Server ………………………….. ………………………….. ………………………….. …………. 14
4.3 Fără stare ………………………….. ………………………….. ………………………….. ……………… 14
4.4 Cache ………………………….. ………………………….. ………………………….. ……………………. 15
4.5 Interfață uniformă ………………………….. ………………………….. ………………………….. …. 16
4.5.1 Identificarea resurselor ………………………….. ………………………….. ……………………. 16
4.5.2 Manipularea resurselor cu ajutorul reprezentărilor ………………………….. ……………. 17
4.5.3 Mesaje autodescriptive ………………………….. ………………………….. ……………………. 17
4.5.4 Hypermedia ca bază a stării aplicației ( HATEOAS ) ………………………….. …………. 17

3
4.6 Sistem stratificat ………………………….. ………………………….. ………………………….. …….. 18
4.7 Cod la cerere (opțional) ………………………….. ………………………….. ………………………. 18
5. Aplicații Mobile ………………………….. ………………………….. ………………………….. ……………. 19
5.1 Istoria dezvoltării aplicațiilor mobile ………………………….. ………………………….. ……. 19
5.2 Aplicațiile mobile în prezent ………………………….. ………………………….. ………………… 20
5.3 Tipuri de aplicații mobile ………………………….. ………………………….. …………………….. 21
5.3.1 Aplicații native ………………………….. ………………………….. ………………………….. …. 21
5.3.2 Aplicații hibride ………………………….. ………………………….. ………………………….. … 21
5.3.3 Aplicații web -based ………………………….. ………………………….. ……………………….. 21
6. Dezvoltarea aplicației ………………………….. ………………………….. ………………………….. …….. 22
6.1 Analiza aplicației ………………………….. ………………………….. ………………………….. ……. 22
6.2 Tehnol ogii folosite ………………………….. ………………………….. ………………………….. ….. 22
7. Concluzii și posibilități de dezvoltare ………………………….. ………………………….. ……………. 23
8. Bibliografie ………………………….. ………………………….. ………………………….. ………………….. 24

4
1. Introducere
De-a lungul timpului, aplicațiile au migrat de la aplicații desktop la aplicații web și mai târziu
la aplicații mobile. Acest ultim pas s-a produs odată cu dezvoltarea dispozitivelor mobile,
preponderent după anul 2010. Schimbările produse au condus la dezvoltarea de noi tehnologii,
dezvoltare care nu par e să se oprească în viitorul apropiat .
1.1 Scurtă prezentare a apl icației
Aplicația dezvoltată se numește „ Food4You ” și are ca scop facilitarea rezervării unei mese
la un restaurant și plasarea unei comenzi, înainte ca persoana care face comanda să ajungă la
restaurant .Aceasta are în centru persoana care dorește să -și facă o rezervare la un anumit
restaurant, un lucru foarte comun în ziua de azi. Dar, pe lângă această opțiune, utilizatorul are și
facilitatea de a plasa o anumită comandă înainte de a ajunge fizic la rest aurant. Totodată, acesta
poate alege restaurantul în funcție de recenziile oferite de ceilalți utilizatori, iar dacă se
răzgândește cu privire la rezervarea creată, o poate anula în limita unui timp impus de către
restaurant. În ceea ce privește restaurant ele, acestea au dreptul să -și modifice oricând meniul,
numărul de locuri disponibile pentru rezervări și să vadă diverse rapoarte în urma rezervărilor și
comenzilor plasate. Totodată, pentru siguranța restaurantelor, plata comenzii se face la crearea
unei rezervări, banii fiind blocați până în momentul în care persoana care a făcut rezervarea
ajunge la restaurant și primește comanda făcută.
Astfel, aplicația vine atât în ajutorul persoanelor care vor să mănânce la un restaurant, cât și
în ajutorul restaura ntelor, utilizatorii primind recomandări în funcție de locația lor și de recenziile
primite.
1.2 De ce o aplicație mobilă?
Aplicația dezvoltată este una mobilă datorită faptului că este mult mai ușor pentru un
utilizator să -și facă o rezervare prin intermediul unui smartphone. Dispozitivele mobile sunt
prezente în ziua de azi peste tot. Aproape fiecare persoană din țările dezv oltate și cele în curs de
dezvoltare deține un smartphone sau are o persoană apropiată care are unul. Astfel, este la
îndemâna oricui să descare o aplicație pe telefon, comparativ cu accesul la un calculator sau un

5
laptop. Telefonul mobil poate fi folosit de oriunde, în timp ce nu oricine are asupra lui un laptop.
În consecință, alegerea făcută se bazează pe accesibilitatea la aplicația oferită.
1.3 Motivarea alegerii temei
Oamenii au încercat mereu să -și facă viața mai ușoară sau mai confortabilă, ajungând să
dezvolte, astfel, sisteme care să îi ajute în viața de zi cu zi. Acestea au evoluat de la simple
aplicații care înlocuiau un banal calculator sau un calendar, la aplicații care azi gestionează
modul în care sunt curățate casele, sunt transferați banii, su nt conduse mașinile. În
consecință, s -au diferite aplicații menite să schimbe viața celor care le utilizează în bine.
Majoritatea aplicațiilor sunt focusate pe rezolvarea problemelor cu care oamenii se
confruntă în fiecare zi: gestionarea timpului, mânca rea, sportul, comunicarea etc. Dintre
acestea, mâncarea este o necesitate zilinică, dar nimeni nu vrea să gătească în fiecare zi. În
unele momente, oamenii simt nevoia de relaxare și ajung să -și comande mâncarea acasă sau
să ia masa la un restaurant. Dar c um poți afla care sunt cele mai bune și mai puțin aglomerate
restaurante din jurul tău? Consider că fiecare dintre noi a trecut prin momentul în care are de
așteptat la restaurant mai mult decât ar fi normal pentru o masă, datorită aglomerației
provocată d e diverși factori precum: popularitatea restaurantului, ora la care se ia masa,
evenimente care au loc în apropiere, plasarea fizică a restaurantului și multe altele. Această
problemă a așteptării după comandă, a pierderii răbdării și a foamei care parcă î n acel
moment s -a instalat mai puternic decât până acum, poate fi rez olvată prin această aplicație.
1.4 Descrierea capitolelor
Lucrarea conține 8 capitole:
 Capitolul 1 : conține o scurtă prezentare a aplicației și motivarea alegerii temei
 Capitolul2 : prezintă câteva aplicații asemănătoare și o analiză comparativă a acestora cu
aplicația dezvoltată
 Capitolul 3 : este format dintr -o introducere în World Wide Web, un scurt istoric al
acestuia, alături de protocoale folosite în aplicații pentru a comunica

6
 Capitolul 4: conține o descriere a serviciilor RESTful, pe ce se bazează acestea și care
sunt principiile lor de bază
 Capitolul 5 : prezintă o descriere a aplicațiilor mobile, pornind primele aplicații până la
cele mai noi platforme existente
 Capitolul 6 : conține o d escriere mai amănunțină a aplicației, prezentarea etapelor de
dezvoltare ale acesteia (analiză, proiectare, implementare) și prezentarea tehnologiilor
folosite
 Capitolul 7 : descrie concluziile observate în urma dezvoltării aplicației și posibilități de
extindere a acesteia
 Capitolul 8 : bibliografia

7
2. Aplicații similare

8
3. Introducere in World Wide Web
3.1 Ce este World Wide Web?
World Wi de Web (WWW) , numit pe scurt și web, reprezintă totalitatea site -urilor și
informațiilor de tip hipertext, legate între ele și care pot fi accesate din rețeaua mondială de
Internet.World Wide Web a fost un succes neașteptat. Ceea ce începuse ca o metodă convenabilă
de a face legătura între laboratoarele de cercetare, a explodat brusc ca mărime.
3.2 Scurt istoric al WWW
Inventatorul World Wide Web este Sir Tim Berners -Lee, un programator britanic. Acesta a
fost născut în Londra, iar părinții săi erau unii dintre primii programatori, care lucram pe primele
calculatoare apărute. După ce a absolvit la Oxford, a devenit progr amator la CERN (Organizația
Europeană pentru Cercetare Nucleară), iar acolo a observat că oamenii de știință aveau dificultăți
în a-și distribui informația. De aici s -a născut ideea care a stat la baza WWW.
În 1989, Berners -Lee și -a expus viziunea despre c eea ce va deveni web -ul într -un document
numit „Information Management: A Proposal”. Până în octombrie 1990, acesta a scris trei
tehnologii fundamentale care au rămas fundația web -ului din zilele noastre:
 HTML (HyperText Markup Language): limbajul web -ului.
 URI (Uniform Resource Identifier): un fel de „adresă” care este unică și utilizată
pentru a găsi orice resursă de pe web. Este de asemenea numit des și URL.
 HTTP (Hypertext Transfer Protocol): permite accesarea datelor de pe web.
Până la finalul anului 1990 prima pagină web a fost a fost postată pe internetul public, iar în
1991, oamenii din afara CERN au fost invitați să intre în noua comunitate web.

9
3.3 Protocoale WWW
3.3.1 HTTP
HTTP (HyperText Transfer Protocol) este protocolul utilizat de programe pentru a comunică
peste WWW. Există o multitud ine de utilizări a HTTP, dar cea mai important ă este comunicarea
bidirecțională dintre clienți web și servere web. Deoarece HTTP folosește protocoale de
transmitere fiabile , garantează că datele trimise nu o să fie deteriorate în tranzit, integritatea lor
fiind păstrată. Transmisia fiabilă este potrivită și pentru developeri, deoarece nu trebuie să își
pună problema distrugerii informației în tranzit sau a duplicării acestei a.
Datorită faptului că serverele web comunică prin HTTP, acestea sunt numite și servere
HTTP. Aceste servere stochează datele din Internet și le furnizează când sunt cerute de către
clienți. Clienții sunt cei care trimit cereri HTTP spre server , iar serve rul le returnează datele prin
intermediul răspunsurilor HTTP. Împreună, clienții HTTP și serverele HTTP formează
componentele de bază ale World Wide Web.
HTTP suportă diferite tipuri de cereri numite metode HTTP. Fiecare cerere HTTP are o
metodă, care îi s pune serverului ce acțiune trebuie să efectueze (de exemplu: să returneze date, să
adauge o intrare nouă într -o bază de date, să șteargă o intrare dintr -o bază de date etc.).
Cele mai comune metode HTTP sunt:
 GET – solicită o reprezentare a resursei specif icate. Cererile care folosesc GET ar
trebui doar să ceară date.
 PUT – salvează datele de la client sub forma unei resurse noi
 DELETE – șterge o anumită resursă de pe server
 POST – trimite o entitate la resursa specificată și cauzează adesea o modificare a
stării acestei resurse
 HEAD – solicită un răspuns identic cu cel al metodei GET, dar fără corpul de
răspuns, se cere doar headerul răspunsului.
Fiecare răspuns HTTP se întoarce cu un cod de stare. Acest cod este format din 3 cifre și îi
spune clientului da că cererea a avut succes sau dacă alte acțiuni sunt necesare pentru a trimite o
cerere corectă.

10
Aceste coduri sunt grupate în 5 clase:
 Răspunsuri informative (100 -199);
 Răspunsuri cu succes (200 -299);
 Redirectări (300 -399);
 Erori ale clientului (400 -499);
 Erori ale serverului (500 -599).
3.3.2 SOAP
Soap (Simple Object Access Protocol) este un protocol folosit pentru schimbul de
informații structurate în implementarea serviciilor web . Scopul său este de a oferi extensibilitate,
neutralitate, veridicitate și independență. Utilizează setul de informații în format XML și se
bazează pe protocoale stratificate, cel mai des pe HTTP.
Soap prezintă o mare importanță în industrie, reprezentând cel mai bun efort de a
standardiza infrastructura tehnologică în ceea ce p rivește sistemele distribuite, bazate pe
comunicare prin intermediul XML -urilor. În ciuda a toate, SOAP este relativ simplu. Acesta este
focusat pe cele mai comune aspecte ale programării distribuite, oferind următoarele:
 Un mecanism pentru a defini unitat e comunicării – În SOAP toată informația este
împachetată într -un mesaj clar, identifi cat ca mesaj SOAP. Acesta poate avea un corp, în
care poate fi folosite arbitrar taguri XML. Poate avea oricâte antete este nevoie, care
încapsulează informație din exter iorul corpului mesajului.
 Un model de procesare – Acesta definește un set de reguli bine știut pentru a procesa
mesajele SOAP în software. Modelul de procesare SOAP este simplu, dar este cheia de a
folosit protocolul cu succes, în special când sunt folosit e și extensii.
 Un mecanism pentru gestionarea erorilor – utilizând SOAP se identifică sursa și cauza
unei erori și se permite schimbarea de informație între participanție pentru rezolvarea
erorii.
 Un model extensibil – Acesta utilizează antete SOAP pentru a implementa extensii
arbitrare deasupra protocolului. Antetele conțin elemente de extensibilitate care
călătoresc împreună cu mesajul și pot fi vizate în momente specifice de -a lungul
schimbului de mesaje.

11
 Un mecanism flexibil pentru reprezentarea datelor – Acest mecanism permite schimbul
de date deja serializat în diferite formate (text, XML și altele) ca pe o convenție pentru
reprezentarea abstractă a structurilor de date.
 O convenție pentru reprezentarea RPC -urilor (Remote Procedure Calls) și a răspunsu rilor
ca mesaje SOAP, RPC -urile fiind cea mai comună metodă de comunicare a sistemelor
distribuite
 Un framework de legare al protocolului – Framework -ul definește o arhitectură pentru
construirea legăturilor folosite la trimiterea și primirea mesajelor SOA P. Acesta este
utilizat pentru a suplimenta legătura care mută mesajele SOAP printre conexiunile HTTP,
deoarece HTTP este un protocol omniprezent în Internet.
3.3.3 SSL
SSL (Secure Sockets Layer) este un protocol omniprezent, utilizat în majoritatea
tranzacțiilo r securizate din Internet. Esential, protocolul transformă un protocol de transport
de încredere (precum TCP) într -un canal de comunicare securizat potrivit pentru a transmite
informații sensibile. Aplicațiile în care este încorporat protocolul sunt pretut indeni.
SSL protejează canalul de comunicare, putând adăuga, de asemenea, și autentificarea (pe
partea clientului, opțional și pe cea a serverului). Acesta poate securiza orice legătură dintre 2
puncte și nimeni din exterior, care nu monitorizează conexiu nea nu poate face nimic pentru a
o distruge sau pentru a câștiga acces neautorizat la datele sensibilie trimise. SSL oferă
infrastructură standard de comunicare care completează aplicațiile și poate fi folosit aproape
invizibil.
Acesta furnizeaza componen te foarte puternice, care trebuie folosite de orice sistem
securizat. Mecanisme generale de autentificare, ca parola Telnet sau autentificarea HTTP
devin foarte puternice când sunt executate folosind SSL, comparativ cu folosirea TCP. SLL
criptează conexiun ea, nu datele care se primesc și care se trimit și nu conține niciun
mecanism de protecție a parolei sau a utilizatorului (doar conexiunea este autentificată) .
Performanța protocolului SSL poate fi amplificată de componente hardware ale sistemelor
între ca re se efectuează comunicarea.

12
Acesta funcționează după următorul model: (todo: refacere diagramă)

3.3.4 WebSocket
WebSocket reprezintă un protocol de comunicare, care permitere deschiderea unei sesiuni de
comunicarea interactivă în două sensuri peste o conexiune TCP. WebSocket -urile alături de
WebWorker -i fac un pas cu adevărat enorm în aducerea funcționalităților desktop la browsere
web. Concurența și multithreadingul nu au funcționat cu adevărat niciodată în lumea postback,
au fost doar simulate într -o manieră restrictivă.
Pentru a fi folosit, trebuie ca atât serverul, cât și clientul să suporte protocolul. Acesta
facilitează transferul în timp real de date, permițând serverului să trimită date clientului, chiar
dacă acesta din urmă nu le -a cerut.
Astfel, este foarte util în ceea ce privește trimiterea de notificări. A avut succes chiar din
momentul în care a apărut, deoarece facilitează transmiterea urgentă a datelor și adăugare în
aplicațiile deja existente nu presupune un efort prea mare.

13
4. Servic ii RESTful
4.1 Rest
REST(Representational State Transfer) este folosit pentru a construi servicii Web care sunt
ușor de menținut și scalabile. Un serviciu care este construit pe baza unei arhitecturi REST este
numit serviciu RESTful. Protocolul de bază pentru REST este protocolul HTTP. Practic,
înseamnă că un server care are o resursă poate primi o de la un client o cerere pentru o
„reprezentare” a resursei respective. De exemplu: dacă resursa este o postare a unui blog, stocată
într-o bază de date, atunci „rep rezentarea” sa poate fi o simplă listă de valori din baza de date.

ROA(Resource -Oriented Arhitecture) reprezintă un mod de a transforma o problemă într -un
serviciu web RESTful: un aranjament de URI -uri, HTTP și XML care lucrează ca restul web –
ului. Constrângerile arhitecturii REST affectează următoarele proprietăți arhite cturale:
 performanța în interacțiunea dintre componente, care, de mult ori, este factorul dominant
în percepția utilizatorului
 scalabilitatea, care permite suportul a unui număr mare de componente și interacțiuni
între componente
CLIENT
BAZĂ DE DATE
SERVER
3.Baza de date returnează
postarea de pe blog.
1.Clientul cere o reprezentare
a unei postă ri de pe blog.
2.Serverul interoghează baza de
date pentru a obține postare.
4.Serverul creează o reprezentare
JSON a postării și o trimite clientului.

14
 simplicitatea unei interfețe uniforme
 vizibilitatea comunicării dintre componente
 postabilitatea componentelor ??
 fiabilitatea în rezistența la defecțiuni la nivel de sistem în prezența defecțiunilor la nivel
de componente, conectori sau date
Roy Fielding, cel care a creat conceptul de REST, susține că pentru ca un API să fie
considerat RESTful trebuie să îndeplinească constrângerile REST (exceptând una opțională).
Cele 6 constrângeri sunt următoarele: client -server, fără stare, cache, interfață uniformă, sistem
stratificat și cod la cerere (opțional).
4.2 Client -Server
Prima constrângere este aceea ca sistemul să fie format din clienți și servere. Serverele au
resursele pe care clienții doresc să le folosească.
Există o separare clară a responsabilităților, serverul are grijă d e ceea ce se întâmplă în spate
(stocarea datelor, regulile de business etc.), în timp ce clienții gestionează interfața cu utilizatorul
și experiența acestuia. Separarea introduce posibilitatea coexistării mai multor tipuri de clienți
(portale web, aplicaț ii mobile, chatbots etc.), care să acceseze același server și fiecare dintre ei
poate evolua independent de ceilați clienți și de server. Separarea reduce, de asemenea,
complexitatea serverului, care nu trebuie să gestioneze aspecte ale interfeței cu utili zatorul, fapt
care îmbunătățește scalabilitatea.
Este important faptul că în majoritatea cazurilor protocolul HTTP este cel folosit pentru a
dezvolta comunicarea dintre server și clienți, dar nu există nicio constrângere care să forțeze
utilizarea acestuia în momentul dezvoltării serviciilor RESTful.
4.3 Fără stare
Pentru a simplifica interacțiunea dintre servere și clienți, a doua constrângere reprezintă
faptul că între ei trebuie să se dezvolte o comunicare fără stare. Acest lucru indică faptul că toate

15
informațiile despre sesiunea clientului sunt reținute de către client, în timp ce serverul nu are
niciun detaliu referitor la aceste informații. În consecință, nu trebuie să există cookie -uri pentru
browsere, variabile de sesiune și alte caracteristici car e să indice starea.
Pe deoparte, consecința acestei constrângeri constă în faptul că fiecare cerere trebuie să
conțină toate informațiile necesare pentru a fi executată, deoarece nu se poate baza pe nicio
informație de context. Pe de altă parte, constrâng erea simplifică considerent serverul, deoarece
acesta nu mai reține informații despre sesiunea clientului sau resursele dintre cereri, iar în ceea ce
privește scalabilitatea, serverul poate elibera rapid resursele după ce cererea s -a încheiat. De
asemenea, face sistemul mai ușor de înțeles, informațiile dintr -o cerere putând fi vizualizare ușor,
la fel și răspunsul rezultat. Totodată, clientului îi va fi mai ușor să -și revină în urma unui eșec,
având în vedere că datele serverului nu au fost corupte sau pie rdute și o cerere care a eșuat poate
fi retrimisă.
4.4 Cache
Ultima constrângere între comunicarea client -server este cea că răspunsurile de la server pot
fi marcate ca cacheable sau non -cacheable.
Un cache eficient poate reduce numărul de interacțiuni dintre server și client, ceea ce aduce
contribuții pozitive la performanța sistemului, cel puțin, din perspectiva utilizatorului. Alte
protocoale, care folosesc HTTP doar ca o metodă convenabilă de a trece de firewall -uri
(utilizând POST) pierd din vedere perfoma nța care poate fi îmbunătățită din caching -ul HTTP.
Acest cache se poate găsi oriunde între server și client. Poate fi un server proxy, un reverse
proxy sau chiar un cache local al clientului, spre exemplu: memoria locală a unui browser. Dacă
este implicat un cache local, un client ar putea parcurge API -ul, cu o singură solicitare de rețea
(sau chiar fără) implicată, deoarece majoritatea solicitării potențiale ar fi accesări în cache .

16

4.5 Interfață uniformă
Ceea ce separă REST de celelalte stiluri arhitecturale este cea interfața uniformă, introdusă
de cea de -a patra constrângere. Interfața uniformă are rolul de a decupla interfața de
implementare, fapt care duce la simplificarea interacțiunilor, aproape oricine putând înțelege
ușor interfața. Această constrângere are la bază 4 sub constrângeri:
4.5.1 Identificarea resurselor
Stilul REST este centralizat în jurul resurselor. Se diferențiază astfel de stilurile SOAP sau
RPC care sunt modelate în jurul procedurilor sau a metodelor. Pe scurt , o resursă reprezintă orice
lucru care poate fi numit. În software -ul entreprise, resursele sunt de obicei entitățile din
domeniu , iar la nivelul implementării, reprezintă de obicei tabelele din baza de date. Este
important de subliniat faptul că REST nu este un „SQL pentru web”, unde există o limitare la
operațiile CRUD aplicate pe tabelele unei baze de date. Pot fi modelate procese de business
avansate care pot fi expuse ca resurse . Fiecare resursă dintr -un design RESTful trebuie să fie
identificată unic printr -un URI, iar identificatorul trebuie să fie unic, chiar și în momentul în care
CLIENT
SERVER
CACHE
GET /
Există în cache
GET /users
Există în cache
Nu există în cache GET /users/1234
GET /user/1234/messages
Răspuns

17
resursa suferă modificări. În consecință, fiecare resursă care este expusă printr -un API REST
trebuie să aibă identificatorul său unic.
4.5.2 Manipularea resurselor cu ajutorul reprezentărilor
A doua sub constrângere a interfeței uniforme este cea că resursele trebuie să fie manipulate
doar prin intermediul reprezentărilor. Acest lucru denotă faptul că, niciodată, clientul nu o să
interacționeze direct cu resursa serverului (spre exemplu: clientul nu o să ruleze instruncțiuni
SQL asupra bazei de date a serverului ). Când clientul dorește să modifice o resursă, acesta
primește reprezentarea resursei, modifică reprezentarea cu noile date, o trimite la server și îi cere
să modifice r esursa conform reprezentării primite. Beneficiul care apare este reprezentat de
evitarea unei cuplări strânse între client și server. Este, de asemenea, mai ușor pentru client,
deoarece nu este nevoit să înțeleagă tehnologia și arhitectura din spatele serv erului.
4.5.3 Mesaje autodescriptive
Fiecare cerere sau răspuns este trebuie să includă destulă informație pentru destinatar pentru
a fi înțeleasă. Fiecare informație trebuie să aibă un tip (de exemplu: „application/json” sau
„application/xml”) care îi comunică receptorului cum trebuie analizat mesajul primit. Totodată,
în momentul utilizării metodelor HTTP, trebuie urmată semnificația lor formală, astfel încât
clienții nu au nevoie de citire suplimentară de informații pentru a înțelege ceea ce se transmite
(spre exemplu: nu se utilizează POST pentru a cere date sau GET pentru a salva date). Beneficiul
este că cele 4 metode HTTP sunt definite clar, astfel un utilizator care știe HTTP, dar nu
cunoaște sistemul, poate înțelege doar din tipul metodei și URI ce face s erviciul.
4.5.4 Hypermedia ca bază a stării aplicației (HATEOA S)
Ultima sub constrângere a interfeței uniforme este un concept simplu care denotă că
hypermedia conduce starea aplicației. Prin urmare, în momentul navigării pe web, este folosit
conceptul de HATEOAS(Hypermedia as the Engine of Application State).
Constrâng erea exprimă că în momentul navigării prin aplicație trebuie folosite link -uri
(hypermedia). Într-un context API REST, acest lucru înseamnă că îmbunătățim reprezentările
resurselor cu link -uri.

18
4.6 Sistem stratificat
Această constrângere spune că aplicația client trebuie să cunoască doar stratul următor în
momentul în care comunică cu serverul și să nu cunoască niciun alt strat intermediar care poate fi
în spatele serverului. În consecință, dacă între client și server este plasat un alt strat (de exemplu
un proxy) nu o să fie afectată comunicarea dintre ei și nu o să fie necesare modificări asupra
clientului. Înseamnă, de asemenea, că putem adăuga un strat de securitate deasupra serviciilor
web și stratul de business cu cel de securitate pot fi separate clar. În final, înseamnă și că serverul
poate comunica cu alte servere pentru a genera un răspuns clientului.
4.7 Cod la cerere (opțional)
Ultima constrângere REST este una opțională și indică serverul poate extinde
funcționalitățile clientului în timpul execuției, trimițând cod care ar trebui executat (ca și Java
Applets sau Javascript). Acest obicei este foarte comun în paginile web, când un browser
accesează o pagină, aproape de fiecare dată descarcă cod Javascript specific paginii și, astfel,
browserul funcțione ază prin cod la cerere.

19
5. Aplicații Mobile
Tehnologiile mobile remodelează societatea, comunicațiile și economia globală. Odată cu
apariția smartphone -urilor și tabletelor care au depășit numărul calculatoarelor și laptopurilor,
modul în care oamenii accesea ză, utilizează și distribuie informația s -a schimbat. Dispozitivele
mobile și aplicațiile digitale le permit utilizatorilor deschidererea de business -uri, accesul la
servicii medicale, comunicate oficiale și metode complete de a efectua tranzacții online.
Totodată, aceste tipuri de dispozitive și aplicații au ajutat la reducerea inegalității sociale, au
crescut participarea comunităților la viața civică, au crescut nivelul educației și au ajutat la
dezvoltarea domeniului economic. Această revoluție a modulu i în care consumatorii accesează
informația reprezintă un punct fundamental în istoria umanității. Pentru prima după, oamenii sunt
capabili să se conecteze cu ceilalți într -un mod care nu implică costu ri mari și este convenabil .
5.1 Istoria dezvoltării aplicaț iilor mobile
Dacă ne întoarcem în istoria aplicațiilor mobile, se poate observa că totul a început de la
câteva jocuri Java, un calculator sau un calendar lunar, care au apărut toate sub categoria de
„aplicații mobile”. Primul smartphone a fost anunțat în anul 1993, pentru utilizarea generală de
către IBM și era echipat cu caracteristici precum: o listă de contacte, un calendar, un ceas și un
calculator. Următoarea mare realizare a fost smartphone -ul BlackBerry în anul 2002 și aveam
integrat conceptul inova tiv de email wireless.
Următoare inovație a fost Symbian, dezvoltat de compania Symbian Ltd creată prin unirea a
4 mari influenți din domeniul mobile: Ericsson, Motorola, Nokia și PSION. Până în 2008, aceștia
au avut un sistem de operare omniprezent, care a fost capabil să ruleze pe aproximativ 250 de
milioane de dispozitive. Nokia a lucrat în continuare la dezvoltarea sistemului Symbian, din care
s-a născut platforma S60, folosită mai apoi și de Samsung și LG.
Mai târziu, smartphone -urile și iphone -urile a u evoluat și au ajuns să fie folosite până în ziua
de azi, ușurând viața de zi cu zi a milioane de persoane.

20
5.2 Aplicațiile mobile în prezent
În prezent există milioane de aplicații mobile, printre care se numără cele pentru rețelele
sociale, călătorit, să nătate, banking, fitness, știri, jocuri și multe altele. În Apple Store sunt
adăugate mai mult de 20.000 de aplicații lunar. Statisticile arată că descărcările totale de aplicații
pentru iPhone depășesc 30 de miliarde, în timp ce utilizatorii Android au de scărcat peste 15
miliarde de aplicații.
Industria mobilă a remodelat business -ul din zilele noastre. Indiferent de domeniu, orice
organizație are nevoie să integreze ultimele tehnologii mobile pentru a atinge dezvoltarea
maximă și a ajunge la publicul țin tă. În ceea ce privește statisticile, se așteaptă ca aplicațiile
mobile să depășească 189 de miliarde de dolari americani în anul 2020.

21
5.3 Tipuri de aplicații mobile
Aplicațiile pot fi categorizate după diferite criterii, dar cele mai comune sunt: native, hibride
sau web -based.
5.3.1 Aplicații native
Toate aplicațiile care țintesc o anumită platformă se numesc aplicații native. Prin urmare, o
aplicație destinată pentru IOS nu o să ruleze pe Android. Ca o consecință, majoritatea
companiilor dezvoltă aplicații pentru multiple platforme. În timp ce dezvolă aplicațiile,
programatorii incorporează cele mai bune module, ținând cont de performanță, consistență și o
experiență a uti lizatorului cât mai bună. Utilizatorii nu sunt limitați în ceea ce privește utilizarea
acestor aplicații și ele încorporează interfețe specifice dispozitivului. În plus, aceștia trec de la o
aplicație la alta fără a depunde prea mult efort.
Motivul princi pal pentru care au fost create acest timp de aplicații este că acestea asigură cea
mai bună performanță a un sistem de operare specific.
5.3.2 Aplicații hibride
Conceptul de aplicații hibride este un mix al aplicațiilor native și a celor web -based. Aplicații
dezvoltate utilizând Apache Cordova, Xamarin, React Native și alte tehnologii similare se
încadrează în această categorie. Acestea au fost create pentru a suporta tehnologiile web și native
pe platforme multiple. Mai mult de atât, aceste aplicații sunt mai u șor și mai rapid de dezvoltat,
deoarece implică cunoașterea unui singur limbaj de programare, care este utilizat pentru aplicații
pe diverse sisteme de operare.
În ciuda acestor avantaje, aplicațiile hibride prezintă performanțe mai mici și, adesea, nu
oferă același aspect și experiență pentru utilizator, precum aplicațiile native.
5.3.3 Aplicații web -based
O aplicație web -based este creată folosind HTML, CSS și JavaScript, iar accesul la internet
este mereu necesar pentru aplicațiile care aparțin acestui grup. A cestea folosesc mai puțină
memorie, comparativ cu cele hibride sau native. Având în vedere că datele se află pe un server
din Internet, utilizatorul le poate accesa de pe orice dispozitiv conectat la internet.

22
6. Dezvoltarea aplicației
6.1 Analiza aplicației
6.2 Tehnologii folosite

23
7. Concluzii și posibilități de dezvoltare

24
8. Bibliografie
1.
2. David Gourley and Brian Totty – „HTTP – The Definitive Guide”, O’Reilly Media, Inc,.
2002
3. History of the Web – https://webfoundation.org/about/vision/history -of-the-web/
4. Kenneth Lange – „The little book on Rest Services” , Copenhagen, 2016
5. James Snell – „Programming Web Services with SOAP” , O’Reilly Media, Inc.,
December 2001
6. Leonard Richardson and Sam Ruby – „RESTful Web Services” , O’Reilly Media, Inc.,
May 2007
7. Rolf Oppliger – „SSL and TLS Theory and Practice”, second edition, Artech House
Publishers
8. Vangos Pterneas – „Getting started with HTML5 and WebSocket Programming” , Packt
Publishing Ltd. , August 2013
9. https://acodez.in/evolution -mobile -apps
10. https://tech.co/news/mobile -app-history -evolution -2015 -11
11. https://www.mobileappdaily.com/mobile -app-development -trends
12. https://en.wikipedia.org/wiki/Mobile_app