FUNDAȚIA PENTRU CULTURĂ ȘI ÎNVĂȚĂMÂNT IOAN SLAVICI TIMIȘOARA [302239]

FUNDAȚIA PENTRU CULTURĂ ȘI ÎNVĂȚĂMÂNT “IOAN SLAVICI” TIMIȘOARA

UNIVERSITATEA “IOAN SLAVICI” [anonimizat]. univ. dr . Titus SLAVICI

ABSOLVENT: [anonimizat] 2016 –

FUNDAȚIA PENTRU CULTURĂ ȘI ÎNVĂȚĂMÂNT “IOAN SLAVICI” TIMIȘOARA

UNIVERSITATEA “IOAN SLAVICI” [anonimizat]. univ. dr . Titus SLAVICI

ABSOLVENT: [anonimizat]2016-

Cuprins

Pagina

Capitolul 1. Considerații generale…………………………………………………………………………………..4

1.1. HTTP (Hypertext Transfer Protocol)…………………………………………………………………………5

1.1.1. Introducere HTTP)……………………………………………………………………………………………….5

2.1.2. Transferul argumentelor și metode în HTTP…………………………………………………………….7

1.1.3. Erori de HTTP (status codes)…………………………………………………………………………………9

12. REST……………………………………………………………………………………………………………………10

1.2.1. Elemente arhitecturale………………………………………………………………………………………….12

1.2.2. Arhitectura…………………………………………………………………………………………………………11

1.2.3. Serviciul web REST……………………………………………………………………………………………..13

1.3. Slim Framework……………………………………………………………………………………………………15

1.3.1. Middlewares……………………………………………………………………………………………………….15

1.3.2. Hooks………………………………………………………………………………………………………………..17

1.3.3. Response………………………………………………………………………………………………………………17

1.3.4. Flash Messages…………………………………………………………………………………………………..19

1.4. Backbone.js…………………………………………………………………………………………………………..19

1.4.1. Backbone.Events………………………………………………………………………………………………..20

1.4.2. Backbone.Model………………………………………………………………………………………………….21

1.4.3. Bacbone.Collection…………………………………………………………………………………………………22

1.5. Twitter Bootstrap……………………………………………………………………………………………………24

1.5.1. Ce oferă Bootstrap?……………………………………………………………………………………………….25

1.5.3. Utilizare Bootstrap……………………………………………………………………………………………..25

1.5.2. Stiluri……………………………………………………………………………………………………………………27

Capitolul 2. Baze conceptuale ale lucrării………………………………………………………………………..29

2.1. Scurta descriere a aplicației

2.2. Interfața paginii de acces

2.3. Photoshop………………………………………………………………………………………………………………..30

Capitolul 3. Date inițiale în elaboarea aplicației…………………………………………………………….31

Capitolul 4. Construcția aplicației…………………………………………………………………………………37

Concluzii ……………………………………………………………………………………………………………………..41

Bibliografie………………………………………………………………………………………………………………..42

INTRODUCERE

Istoria Internetului începe odată cu evoluția calculatoarelor și a rețelelor de comunicații (1950 și 1960). Primul proiect de dezvoltare și realizarea, a unei rețele fiind lansat în 1960, fiind un proiect militar care consta în crearea unei rețele de calculatoare între cele mai importante centre militare ale SUA. Centrele erau interconectate multiplu, ca în cazul unui atac nuclear, chiar dacă o parte a legăturilor s-ar fi distrus, rețeaua totuși ar fi putut rezista să țină legătura între supercalculatoarele DoD (Department of Defense).

Chiar dacă primele rețele au aparținut domeniului militar, ele s-au extins în domeniul cercetării academice, legând diferite universități, pentru ca în 1990 rețeaua să fie deschisă pentru toată lumea. În ciuda numeroaselor încercări ale diverselor organizații și guverne, nimeni a reușit să controleze cu adevărat puterea internetului. Acesta este compus din multe rețele individuale dar nimeni nu îl posedă în totalitate.

Utilizatorii pot avea acces la o gamă foarte largă de informații, din toate domeniile globale. Unul din topic-urile des accesate de persoanele ce navighează pe internet în ziua de astăzi este cel legat de lumea cinematografică, a rețelelor de socializare și a celor de muzică.

În trecut, oamenii nu aveau posibilitatea să afle anticipat informații despre un anumit film, despre lansarea lui(data/ țara de lansare), actorii principali sau subiectul acțiunii filmului. Odată cu dezvoltarea internetului, s-au dezvoltat și site-urile care oferă aceste informații, destinate atât criticilor de filme, cât și persoanelor obișnuite care pur și simplu doresc să afle noutățile în materie de cinema.

Din acest motiv, am ales să realizez o aplicație web pe această temă, care să cuprindă o bază de date cu o serie de filme bine cotate și vizionate personal. Dacă filmul pe care îl caută un utilizator nu se află în baza de date a aplicației, utilizatorul are posibiltatea să-și caute filmul dorit utilizând aplicația care îi caută, îi găsește și îi afișează informațiile despre filmul dorit indiferent de genul filmul.

În această lucrare științifică am introdus câteva noțiuni de teorie cât și aplicații practice ale conceptelor analizate. Lucrarea cuprinde 4 capitole, având următoarea structură:

-Introducere: În această parte am prezentat tema abordată în lucrarea ștințifică, domeniul de aplicare al noțiunilor prezentate și structurarea documentului.

Capitolul 1:Considerații generale .

Capitolul 2: Bazele conceptuale ale lucrării .

Capitolul 3: Date inițiale în elaborarea aplicației .

Capitolul 4: Construcția .

Capitolul 5: Elemente de utilizare.

Concluzii: Această parte a lucrării cuprinde prezentarea punctului de vedere personal în ceea ce privește aplicația dezvoltată și viitoare upgrade-uri ale web site-ului realizat.

CAPITOLUL 1. CONSIDERAȚII GENERALE

1.1. HTTP (Hypertext Transfer Protocol)

1.1.1. Introducere HTTP

Conform titlului bibliografic nr.[1], Hypertext Transfer Protocol (HTTP) este un protocol de aplicație pentru sistemele informatice distribuite, colaborative, hypermedia și metoda cea mai fracventată utilizată pentru accesarea informațiilor în Internet. HTTP este fundamentul comunicării de date pentru World Wide Web. Protocolul HTTP este un protocol de tip text, fiind protocolul "implicit" al WWW. Adică, dacă un URL nu conține partea de protocol, aceasta se poate considera ca fiind http. HTTP presupune că pe calculatorul destinație rulează un program care înțelege protocolul. Fișierul trimis la destinație poate fi un document HTML (abreviație de la HyperText Markup Language), un fișier grafic, de sunet, animație sau video, de asemenea un program executabil pe server-ul respectiv sau un editor de text. După clasificarea modelului de referință OSI, protocolul HTTP este un protocol la nivel aplicație. Realizarea și evoluția sa este coordonată de către WWW(World Wide Web) Consortium (W3C).

HTTP oferă o tehnică de comunicare prin care paginile web se pot transmite de la un computer aflat la distanță spre propriul computer. Dacă se apelează un link sau o adresă de web cum ar fi http://www.example.com, atunci se cere calculatorului host să afișeze o pagină web (index.html sau altele). În prima fază numele (adresa) www.example.com este convertit de protocolul DNS într-o adresă IP. Urmează transferul prin protocolul TCP pe portul standard 80 al serverului HTTP, ca răspuns la cererea HTTP-GET. Informații suplimentare ca de ex. indicații pentru browser, limba dorită ș.a. se pot adăuga în header-ul (antetul) pachetului HTTP. În urma cererii HTTP-GET urmează din partea serverului răspunsul cu datele cerute, ca de ex.: pagini în (X)HTML, cu fișiere atașate ca imagini, fișiere de stil (CSS), scripturi (Javascript), dar pot fi și pagini generate dinamic (SSI, JSP, PHP și ASP.NET). Dacă dintr-un anumit motiv informațiile nu pot fi transmise, atunci serverul poate trimite înapoi un mesaj de eroare. Modul de desfășurare a acestei acțiuni (cerere și răspuns) este stabilit în specificațiile HTTP.

Sesiune HTTP.

O sesiune HTTP este un protocol client-server, o sesiune HTTP conform bibliografiei cu numărul [2], este format din trei faze:

Clientul a stabilește o conexiune TCP (sau conexiunea adecvată în cazul în care stratul de transport nu este TCP).

Clientul trimite o cerere și apoi așteaptă răspunsul.

Server procesează cererea și trimite înapoi răspunsul său, care conține un cod de stare și datele corespunzătoare.

Stabilirea unei conexiuni.

Pentru că HTTP-ul este un protocol client-server, întotdeauna clientul este cel care stabilește conexiunea. Deschiderea unei conexiuni HTTP este într-adevăr  stabilirea unei conexiuni în stratul de transport care stau la baza, de obicei TCP.

Cu protocolul TCP, portul implicit pentru un server HTTP pe un calculator este portul 80, deși altele sunt adesea folosite, cum ar fi 8000 sau 8080. URL-ul unei pagini pentru a prelua conținutul , numele de domeniu și numărul de port, deși acesta din urmă poate fi omis în cazul în care este de 80.

Mesaje HTTP

Conform titlului din bibliografia situată cu numărul[3],mesajele HTTP constau în cereri de la client la server și răspunsurile de la server la client.

HTTP-message = Request | Response ; HTTP/1.1 messages

generic-message = start-line

*(message-header CRLF)

CRLF

[ message-body ]

start-line = Request-Line | Status-Line

Ambele tipuri de mesaj constau dintr-un start-linie, zero sau mai multe câmpuri antet, o linie goală care indică sfârșitul câmpurilor de antet, si posibil un „message-body”.

Versiunile (Conform titlului bibliografic nr. [4])

− HTTP/0.9 – prima versiune a fost realizată de către Tim Berners-Lee și echipa sa. Această versiune este o versiune foarte simplistică, dar cu destule neajunsuri, fiind înlocuită destul de repede de alte versiuni;

− HTTP/1.0 – aceasta versiune introdusă în 1996 prin RFC1945, a adus numeroase îmbunătățiri;

− HTTP/1.1 – Aceasta versiune aduce foarte multe îmbunătățiri și reparații a neajunsurilor din versiunille anterioare.

În prezent se folosesc doar două versiuni ale protocolului, HTTP/1.0 și HTTP/1.1. La prima versiune HTTP/1.0 se poate stabilii o nouă conexiune TCP înaintea cererii, iar după transmiterea răspunsului conexiunea trebuie închisă. Atunci, in cazul unui document de tip HTML care cuprinde 10 imagini, atunci, in acest caz vor fi necesare 11 conexiuni TCP, pentru ca pagina să fie afișată complet (în browser). La versiunea 1.1 se pot emite mai multe cereri și răspunsuri pe aceeași conexiune TCP. Astfel pentru, documentul HTML cu 10 imagini necesită doar o singură conexiune TCP. Deoarece, datorită algoritmului Slow-Start, viteza conexiunii TCP este la început mică, dar fiind folosit doar o singură dată, se scurtează semnificativ durata totală de încărcare a paginii. La aceasta se adaugă și faptul că versiunea 1.1 poate relua și continua transferuri întrerupte.

La HTTP este riscul de a se putea pierde informațiile cererilor vechi (în concluzie, este un protocol fără reținerea stării). Prin utilizarea de cooki-uri în header, se pot realiza însă aplicații care pot utiliza informații de stare (opțiunile utilizatorului din sesiunea actuală, cum ar fi coș de cumpărături, rezervări, înscrieri ș.a.). Chiar și o recunoaștere a utilizatorului este astfel posibilă. În mod normal se pot citi informațiile transmise care parcurg rețeaua pe computere și rutere. Prin HTTPS transferul se poate și cripta.

Versiunea cea mai recentă se poate utiliza în chat-uri prin utilizarea MIME-tip-ului multipart/replace, care reînnoiește complet conținutul ferestrei browser-ului. Noua versiune permite pe lângă preluarea datelor, și transmiterea lor la server. Cu ajutorul metodei "PUT" web-designerii pot să-și publice paginile web pe webserver prin WebDAV, iar prin metoda "DELETE" ei pot chiar și șterge pagini de pe server.

De asemenea, HTTP/1.1 mai poate oferii și metoda "TRACE" prin care se poate urmări calea spre webserver, și verificarea datelor dacă au fost corect transferate. Așadar, se poate urmări calea prin diferite proxi-uri spre webserver, echivalent cu un traceroute la nivel de aplicație.

1.1.2. Transferul argumentelor și metode în HTTP.

Două metode de cereri în HTTP sunt :GET și POST.

POST – Sunt datele care urmează să fie prelucrate si prezentate la resursa specificată.

POST – Sunt datele care urmează să fie prelucrate și prezentate la o resursă specificată

Metoda GET:

Să se rețină că șirul de tip interogare (perechi nume / valoare) este trimis în URL – ul unei cereri GET:

Datele care sunt transmise către server prin GET, apar la finalul URL-ului, așa cum au fost introduse; acest lucru poate fi un dezavantaj când este vorba de date senzitive, dar ajută la modificarea ușoară a datelor pentru retrimitere.

Cantitatea de date GET, depinde de lungumea maximă permisă a URL-ului, la care în Internet Explorer este de 2.083 caractere. Așadar prin GET, nu se vor putea transmite prea multe date.

Rezultatul unui request GET, poate fi preluat din cache-ul browser-ului sau al proxy-ului web. Trebuie că URL-ul să fie diferit la fiecare request nou pentru a fi siguri că datele reale sunt preluate.

Caracterele speciale pot fi codificate folosind atributul enc-type al formularului; dezavantajul este că această codificare va reduce cantitatea de date ce pot fi transmise (ex. 3 caractere japoneze sunt reprezentate cu ajutorul a 42 caractere normale: %26%2312454%3B%26%2312455%3B%26%2312502%3B).

În PHP, elementele formularului sunt disponibile prin intermediul variabilei globale $_GET (sau prin $_REQUEST).

Metoda POST:

Să se rețină că șirul de tip interogare (perechi nume / valoare) este trimis în corpul mesajului HTTP unei cereri POST:

Cantitatea de date ce poate fi transmisă prin POST poate fi restricționată doar de către serverul web, deși nu există o limitare reală .

Datele transmise prin POST nu apar în URL și nu pot fi alterate ușor, ceea ce oferă un oarecare grad de securitate .

În mod implicit, datele preluate prin POST nu sunt puse în cache-ul de la browser sau proxy-server; astfel folosind această metodă vor fi afișate întotdeauna datele reale

Codificarea caracterelor speciale se poate realiza că și la GET folosind atributul enc-type al formularului (application/x-www-form-urlencoded); avantajul este că nu există limitări de cantitate a datelor .

În PHP, elementele formularului sunt disponibile prin intermediul variabilei globale $_POST (sau prin $_REQUEST) .

Pe lângă considerentele de mai sus, trebuie avut în vedere și o recomandare generală: GET ar trebui folosit pentru operațiile care nu modifică nimic pe server, în timp ce POST ar trebui folosit pentru operațiile de modificare/actualizare/ștergere.

Conform punctului nr. [5] din lista bibliografică, am extras metodele și tipuri de erori http. Metodele disponibile sunt :

GET

– Este folosit când serverului i se cere o resursă.

HEAD

– Serverul poate returna doar antetul resursei, ceea ce permite clientului să inspecteze antetul resursei.

PUT

– Încărcare documente pe server.

POST

– Trimite date de intrare către server.

DELETE

– Șterge resursa specificata.

TRACE

– Este o metodă folosită pentru diagnosticare.

OPTIONS

– Este folosit pentru identificarea capacităților serverului Web, înainte de a face o cerere.

CONNECT

– Este o metodă folosită în general de serverele intermediare.

PATCH

– Este utilizat pentru a aplica modificări parțiale asupra unei resurse.

1.1.3. Erori de HTTP (status codes)

Erorile de HTTP sunt clasificate în 5 clase (categorii):

1xx – erori informaționale: această clasă a status-ului indică un răspuns provizoriu al serverului și conține numai linia de status (de răspuns) sau alte aplicații opționale. Nu sunt aplicații necesare pentru acestă clasa de răspuns/status. Aceste status-uri pot fi ignorate.

2xx – răspuns reușit: clasa de răspuns/status ce indică utilizatorului că cererea a fost primită, înțeleasă și acceptată cu succes.

3xx – redirectări: această clasă de răspuns/status indică faptul că acțiunile următoare vor trebui făcute de browser pentru a putea fi îndeplinita cererea. Cererea ar putea fi direcționată de browser fără a interacționa cu utilizatorul dacă și numai dacă metoda folosită în cea de a doua cerere este „Primit/recepționat” sau „Direcționat/condus”.

4xx – erori ale utilizatorilor: această clasă de mesaje/statusuri este folosită în cazurile în care utilizatorul ar putea greși formularea cererii. Excepția fiind răspunsurule pentru cererile tip „Direcționat/condus”, atunci serverul ar trebui să conțină o intrare cu o explicație a situației erorii și dacă e o eroare temporară sau pemanentă. Aceste răspunsuri sunt aplicabile pentru orice fel de cerere. Browser-ele ar trebui să arate orice intrare cerută de utilizator.

5xx – erori de server: răspunsurile/status-urile ce încep cu unitatea/cifra 5 indică cazurile în care serverul e conștient de greșelile produse sau e incapabil să execute cererea. Excepție facând răspunsul unei cereri „Direcționat/condus”, serverul ar trebui, în acest caz sa includă o afișare cu o explicație a situației de eroare, fie că e temporara sau permanentă.

1.2. REST

Elementele ce descriu stilul arhitectural REST au fost preluate din sursa corespunzătoare punctului nr. [6] din lista bibliografică.

Stilul architectural care stă la baza Web este numit “Representational State Transfer” sau, mai simplu, „REST”. REST a răspuns la necesitatea IETF, pentru un model despre cum ar trebui să funcționeze WEB. Acesta este un model idealizat al interacțiunilor din cadrul unei aplicații Web globale.

REST reprezintă un set coordonat de constrângeri arhitecturale care încearcă să reducă la minimum latența și comunicarea în rețea și, în același timp, încearcă maximizarea și scalabilitatea implementării componentelor. REST permite prinderea și reutilizarea de interacțiuni, substituirea dinamică a componentelor și procesarea de acțiuni de către intermediari, răspunzand astfel nevoilor de distribuire a unui sistem hipermedia la scară Internet.

REST aplicat în HTTP

Hypertext Transfer Protocol (HTTP), are un rol important in arhitectura Web atât ca protocol primar la nivel de aplicație pentru comunicare între componentele Web cât și ca singurul protocol special conceput pentru transferul de reprezentări de resurse. Spre deosebire de URI, au existat un număr mare de modificări necesare pentru ca HTTP să suporte arhitectura modernă Web. REST a fost utilizat pentru a identifica problemele cu implementările HTTP existente.

Domeniile cheie cu probleme în HTTP, care au fost identificate de către REST includ planificarea pentru desfășurarea de noi versiuni de protocol, distincția între răspunsurile de autoritate și non-autoritate, control cu granulatie fina de caching, și diferite aspecte ale protocolului care nu au reușit să fie auto-descriptive. REST a fost, de asemenea, folosit pentru a modela performanța aplicațiilor web bazate pe HTTP și pentru a anticipa impactul acestor extensii, cum ar fi conexiuni persistente și negocierea conținutului. În final, REST a fost folosit mai degraba pentru a limita domeniul de aplicare al extensiilor HTTP standardizate la cele care se încadrează în modelul arhitectural, decât să permită aplicațiilor care folosesc în alte scopuri HTTP să influențeze în mod egal standardul.

Unul dintre obiectivele majore ale REST este de a sprijini implementarea treptată și fragmentată de modificări într-o arhitectură deja implementată. HTTP a fost modificat pentru a susține acest obiectiv, prin introducerea unor cerințe versiunilor, și reguli pentru extinderea fiecărui element de sintaxă a protocolului.

1.2.1. Elemente arhitecturale

REST distinge trei clase de elemente arhitecturale:

Date

Conectori

Componente

Date

Aspectul cheie al REST este starea elementelor de date; componentele sale comunică prin transferul de reprezentări ale stării actuale sau dorite a elementelor de date.

În REST orice care poate fi numit poate fi o resursă. O resursă este o mapare conceptuală a unui set de entități; doar semantica unei resurse trebuie sa fie statică; entitățile se pot modifica în timp. Aceasta înseamnă că entitatea din spatele unei resurse se poate schimba în timp. REST folosește identificatori de resurse pentru a distinge între resurse. Într-un mediu Web identificatorul este un URI (Uniform Resource Identifier ).

Toate componentele REST efectuează acțiuni cu privire la inerpretările resurselor.

Interpretarea este compusă din:

secvență de biți (conținutul)

Interpretare metadate (care descriu conținutul)

Metadate care descriu metadate

Conectori

Conectorii gestionează comunicarea în rețea pentru o componentă.

Conectorii prezintă o interfață generală abstractă pentru comunicarea componentei, conducând la:

Separarea de preocupări

Consolidare simplitate

Comutabilitate

REST încapsulează diferite activități de accesare și transfer de reprezentări în diferite tipuri de conectori:

Client: emite cereri, primește răspunsuri.

Server : așteaptă cereri, emite răspunsuri.

Cache: poate fi situată la conectorul de server sau client pentru a salva răspunsuri, mai poate fi partajată între mai mulți clienți.

Tunnel : cereri de relee.

Resolver : tranformă identificatorii de resurse în adrese de rețea.

Componente

Componentele REST sunt identificate prin rolul lor în cadrul unei aplicații.

Agentul utilizator folosește un conector de client pentru a iniția o cerere și devine destinatarul final al răspunsului.

Serverul de origine utilizează un conector de server pentru a primi cererea și este sursa definitivă de reprezentare a resurselor sale. Fiecare server oferă o interfață generică serviciilor sale ca o ierarhie a resurselor.

Componentele intermediare acționează atat ca și client, cât și ca sever, cu scopul de a înainta cereri și răspunsuri.

1.2.2. Arhitectura

REST definește arhitectura prin introducerea de restricții pe interacțiunile componentei în loc să predefinească topologia unei componente. Se ignoră detaliile de implementare și sintaxă protocol pentru a realiza:

Scalabilitatea interacțiunilor unei componente

Desfășurarea independentă a componentelor

Acceptarea componentelor intermediare care să reducă latentă interacțiunilor

Componentele unei arhitecturi REST pot fi rearanjate dinamic, intermediarii pot fi plasați în fluxul unei reprezentări și acționează similar unui filtru.

REST nu este legat de un anumit protocol, permițând intermediarilor să tranforme reprezentări pe drumul lor prin sistem; acesta oferă o integrare perfectă la diferite protocoale, deși HTTP este protocolul cel mai utilizat pe Internet. În figura 1.2 avem un exemplu de arhitectură.

Figura 1.2. Model de arhitectură (preluat din [Architectural Styles and the Design of Network Based Software Architectures])

Orchestrația serviciilor web REST nu este o mare problemă, deoarece protocoalele sunt deja standardizate, numai structurile de date și URI-urile serviciilor implicate trebuie să fie cunoscute, astfel putem folosi orice limbaj de script cu un suport HTTP decent.

1.2.3. Serviciul Web REST

Pentru a înțelege mai bine stilul arhitectural REST îl vom prezenta cu ajutorul unui exemplu simplu de serviciu web.

Serviciul va oferi această funcționalitate :

Utilizatorul poate încărca o imagine

Metadate pot fi atașate la imagini

Imagini și metadate atașate pot fi șterse

Resurse.

Captarea cheii în REST este resursa, așa că vom începe prin identificarea resurselor din exemplul nostru.

– Picture

– Picture-Collection

Reprezentări.

Fiecare resursă are o reprezentare asociată.

– Picture: binar și XML

– Picture-Collection: XML

Adresare.

Resursele, în cazul nostru, sunt adresabile prin intermediul unui URI. Numai resursele pot fi adresate.

Metode.

HTTP definește un set de metode, iar în exemplul nostru vom folosi GET, PUT, POST și DELETE, iar opțional OPTIONS.

o PUT este folosit pentru a încărca o nouă imagine pe server. Cererea PUT returnează codul de raspuns creat și un URI al resursei create. PUT poate fi efectuată pe /picture. În figura 1.3. avem un exemplu de utilizare al metodei PUT.

Figura 1.3. Utilizare metoda PUT (preluat din [Architectural Styles and the Design of Network Based Software Architectures])

POST este utilizat pentru a adăuga mai multe metadate la resursa abordată. De exemplu, date GPS cum ar fi longitudine și latitudine, care pot fi ușor anexate la resursă. POST poate fi efectuată pe /picture/ID. Returneazaă reprezentarea actualizată a metadatei imaginii și necesită autentificare. În figura 1.4. avem un exemplu de utilizare al metodei POST.

Figura 1.4. Utilizare metoda POST (preluat din [Architectural Styles and the Design of Network Based Software Architectures])

DELETE este utilizat pentru a șterge o resursă. Poate fi utilizată pe /picture/ID și necesită autentificare. Dacă serverul acceptă cererea, codul de raspuns este 202 Accepted. În figura 1.5. avem un exemplu de utilizare al metodei DELETE.

GET este utilizat pentru a prelua o reprezentare a resursei specificate. Nu necesită autentificare și poate fi utilizată pe:

– /picture/index, pentru a obține o listă de imagini disponibile

– /picture/ID cu Accept:text/xml, pentru a obține metadata imaginii și Accept:image/jpeg pentru a obține reprezentarea binară.

În figura 1.6. avem un exemplu de utilizare al metodei GET.

OPTIONS poate fi folosit pentru a returna o descriere a serviciului accesat.

1.3. Slim Framework

Consultând punctul nr. [5] din lista bibliografică, am extras informații referitoare la framework-ul Slim.

Slim este un micro framework PHP care ne ajută să scriem mai rapid aplicații web simple, dar puternice, și API-uri. Mai jos putem observa un exemplu simplu de cod:

1.3 Slim framework are următoarele caracteristici:

Router puternic

Metode HTTP standard și personalizate

Parametrii traseului cu metacaractere și condiții

Traseu middleware

Redare șablon cu vizualizări particularizate

Mesaje instantanee

Cookie-uri securizate cu criptare AES-256

HTTP caching

Manipulare și depanare erori

Arhitectură middleware și cârlig

Configurare simplă

1.3.1. Middlewares

Slim framework implementează o versiune a protocolului Rack. Ca rezultat, o aplicație Slim poate avea middleware-uri care pot inspecta, analiza sau modifica mediul aplicației, cererea și răspunsul, înainte sau după ce aplicația Slim este invocată.

Arhitectura Middleware

Ne putem imagina o aplicație Slim ca fiind nucleul unei mingi acoperite de mai multe straturi. Fiecare strat al mingii este un middleware. Când invocăm aplicatia Slim prin metoda run(), se invocă prima dată cel mai din exterior strat (middleware). Când este gata, stratul de middleware este responsabil pentru invocarea opțională a următorului strat middleware pe care îl înconjoară. Acest proces pătrunde mai adanc spre nucleul mingii, prin fiecare strat middleware, până când nucleul aplicației slim este invocat. Acest proces este posibil deoarece fiecare strat middleware, precum și aplicația Slim în sine, implementează o metodă publică call(). Când adăugăm un nou middleware aplicației Slim, middleware-ul adăugat va deveni un nou strat exterior ce va înconjura stratul din exterior de middleware sau aplicația Slim însăși.

Scopul unui middleware este de a inspecta, analiza sau modifica mediul de aplicare, cererea și răspunsul înainte sau după ce aplicația Slim este invocată. Este ușor pentru fiecare middleware să obțină referințe despre aplicația Slim primară, a mediului ei, cererea și răspunsul aplicației. Modificările aduse obiectelor se vor propaga imediat pe parcursul aplicației și altor straturi de middleware. Acest lucru este posibil deoarece fiecărui strat middleware îi este dată o referință la același obiect al aplicației Slim.

1.3.2. Hooks

O aplicație Slim oferă un set de “cârlige” la care putem înregistra propriile reapelări.

Un “cârlig” reprezintă un moment din ciclul de viață al unei aplicații Slim, când îi va fi invocată o listă prioritară de apelări atribuite cârligului. O apelare este asignată cârligului și este invocată când cârligul este apelat.Dacă mai multe apelări sunt asignate unui singur cârlig, atunci fiecare apelare este invocată în ordinea asignării lor.

O apelare este asignată unui cârlig folosind metoda hook():

Primul argument din codul de mai sus este numele cârligului urmat de apelare. Fiecare cârlig menține o listă de priorități a apelărilor înregistrate. În mod implicit, fiecărei apelări asignate unui cârlig îi este dată prioritatea 10. Dacă vrem să-i dăm prioritatea 7 atunci vom introduce 7 ca al treilea parametru al metodei hook ():

Astfel îi vom asigna prioritatea 7.

Cârligele implicite invocate mereu într-o aplicație Slim sunt urmatoarele:

slim.before

slim.before.router

slim.before.dispatch

slim.after.dispatch

slim.after.router

slim.after

Cârligele customizate pot fi create și invocate într-o aplicație Slim. Pentru a invoca un cârlig customizat folosim applyHook(), care va invoca toate apelările asignate cârligului. Ca și exemplu, vom invoca un cârlig customizat denumit alex:

1.3.3. Response

Fiecare instanță a unei aplicații Slim are un obiect de răspuns. Obiectul de răspuns este o abstracție a răspunsului HTTP al aplicației către clientul HTTP.

Un raspuns HTTP are trei proprietăți primare:

Status

Header

Body

Response Status

Răspunsul HTTP întors la client va avea un cod de stare care indică tipul de răspuns, cum ar fi: 200 OK, 400 Bad Request, 500 Server Error. Putem folosi obiectul de răspuns al aplicației pentru a seta statusul de răspuns al HTTP astfel:

Response Headers

Antetul HTTP este o listă de chei și valori care furnizează metadate despre răspunsul HTTP.

Response Body

Corpul HTTP este conținutul real al răspunsului HTTP livrat clientului.

Response Cookies

Slim oferă metode pentru a trimite cookie-uri cu răspunsul HTTP. Mai jos avem un exemplu prin care putem seta cookie-uri:

Response Helpers

Obiectul de răspuns oferă metode pentru a inspecta și a interacționa cu răspunsul HTTP subadiacent și anume finalizare și redirecționare.

1.3.4. Flash Messages

Slim suportă mesaje flash la fel ca Rails și alte framework-uri mai mari. Mesajele flash ne permit să definim mesaje care vor persista până la urmatoarea cerere HTTP, dar nu mai departe. Acest lucru este util pentru a-i afișa mesaje utilizatorului despre un anumit eveniment sau o eroare care se produce.

Avem trei tipuri de mesaje:

Flash Next

Această metodă stabilesște un mesaj care va fi disponibil în următoarea cerere de vizualizare a șabloanelor:

Flash Now

Această metodă stabilește un mesaj care va fi disponibil în cererea curentă de vizualizare a șabloanelor. Mesajele setate cu această metodă nu vor fi valabile în următoarea cerere.

Flash Keep

Această metodă îi spune aplicației să păstreze mesajele flash existente setate în cererea anterioară, astfel încât să fie disponibile la crererea următoare.

1.4.Backbone.js

Conform punctului nr. [1] din lista bibliografică, am preluat informațiile referitoare la librăria Backbone.js .

Backbone.js este o librarie folosită pentru a oferi structură aplicațiilor web folosind events, models, collections și views conectate la un API cu o interfață RESTful JSON.

RESTful JSON este o interfață care are la bază o structură arhitecturală REST și care folosește formatul JSON pentru reprezentarea informației.

Backbone face parte din familia MV. El ia câte ceva din MVC (Model View Controller), MVP (Model View Presenter) și MVVM (Model View ViewModel).

Model-view-controller (MVC) este un model de arhitectură software utilizat pentru punerea în aplicare a interfețelor. Pe langă faptul că divide aplicația în trei tipuri de componente, MVC definește și interacțiunile dintre ele:

Un controller: trimite comenzi modelului pentru a actualiza starea modelului.

Un model: notifică view și controller, atunci când a existat o schimbare în starea sa.

View: solicită informații de la modelul de care are nevoie pentru a genera o reprezentare pentru utilizator.

Model-view-presenter este o derivare a patern-ului arhitectural MVC.

Model-view-viewmodel este un patern architectural folosit în ingineria software.

Cu Backbone putem reprezenta datele ca modele, care pot fi create, validate, distruse și salvate pe server. Ori de câte ori o acțiune UI provoacă schimbarea atributului unui model, modelul declanșează un eveniment schimbare, astfel toate View-urile care afișează starea modelului pot fi notificate de schimbare, astfel încât acestea sa răspundă în mod corespunzător.

Backbone este o încercare de a descoperi setul minim de date (modele și colecții) și primitivele interfeței utilizatorului (vizualizări și URL-uri) care sunt utilizate în general în construirea aplicațiilor web cu Java Script.

1.4.1. Backbone.Events

Event este un modul care poate fi încorporat la orice obiect, oferindu-i obiectului capacitatea de a lega și de a declanșa evenimente personalizate.

În events avem următoarele obiecte:

On object.on(event, callback, [context])

Leagă o funcție de reapelare la un obiect. Reapelarea va fi invocată atunci când eventul este demis.

Off object.off([event], [callback], [context])

Șterge o funcție de apelare legată la un obiect. Dacă nu este specificat niciun context, toate versiunile reapelării cu diferite contexte vor fi eliminate.

Trigger object.trigger(event, [*args])

Trigger reapelează evenimentul dat.

Once object.once(event, callback, [context])

La fel ca On , numai că se activează o dată înainte să fie demis.

listenTo object.listenTo(other, event, callback)

Îi spune unui obiect să asculte un anume eveniment al altui obiect.

stopListening object.stopListening([other], [event], [callback])

Îi spune unui obiect să nu mai asculte la evenimente.

listenToOnce object.listenToOnce(other, event, callback)

La fel ca listenTo, numai că se activează o dată înainte să fie demis.

1.4.2. Backbone.Model

Modelele sunt inima oricărei aplicații Java, ele conțin date interactive, precum și o mare parte a logicii care le înconjoară: conversii, validări și de control acces. Mai jos vom prezenta câteva modele:

extend Backbone.Model.extend(properties, [classProperties])

Extend stabilește în mod corect lanțul de prototip, astfel subclasele create cu extindere pot fi extinse și subclasate cât de mult dorim.

constructor / initialize new Model([attributes], [options])

Când creăm o instanță a unui model, putem trece valorile inițiale ale atributelor, care vor fi setate pe model. Dacă definim o funcție Inițializare, aceasta va fi invocată atunci când modelul este creat.

get model.get (attribute)

Obține valoarea curentă a unui atribut din model. De exemplu: note.get("title")

set model.set (attributes, [options])

Setează un hash de atribute (unul sau mai multe), pe model.

escape model.escape(attribute)

Similar cu get, numai că întoarce versiunea HTML al unui atribut al modelului.

has model.has(attribute)

Returnează true dacă atributul este setat cu o valoare nenulă sau nedefinită.

unset model.unset(attribute, [options])

Elimină un atribut ștergându-l din hash-ul atributelor interne.

clear model.clear([options])

Șterge toate atributele din model, inclusiv atributul model.

id model.id

O proprietate specială a modelelor, id-ul este un șir arbitrar (id întreg sau UUID).

attributes model.attributes

Proprietatea atributelor este hash-ul intern care conține starea modelului, de obicei o formă a obiectului JSON care reprezintă modelul datelor de pe server.

changed model.changed

Proprietatea de schimbare este hash-ul intern care conține toate elementele care s-au schimbat de la ultima setare.

defaults model.defaults or model.defaults()

Hash-urile implicite pot fi folosite pentru a specifica atributele specifice modelului.

destroy model.destroy([options])

validate model.validate(attributes, options)

Această metodă este nedefinită.

url model.url()

Returnează URL-ul relativ, unde resursa modelului ar fi situată pe server.

clone model.clone()

Returnează o noua instanță a modelului cu atribute identice.

1.4.3. Backbone.Collection

Colecțiile sunt seturi ordonate de modele. Orice eveniment care este declanșat pe un model într-o colecție va fi declanșat și pe colecție direct, pentru comoditate. Modele din Backbone.Collection:

model collection.model

Suprascrie această proprietate pentru a specifica clasa de model pe care colecția o conține.

models collection.models

Acces brut la gama de modele JavaScript din interiorul colecției.

add collection.add(models, [options])

Adaugă un model colecției.

remove collection.remove(models, [options])

Șterge un model din colecție.

reset collection.reset([models], [options])

Înlocuiește o colecție cu o nouă lista de modele.

set collection.set(models, [options])

Metoda set efectuează o actualizare inteligentă a colecției cu lista metodelor.

get collection.get(id)

Ia un model dintr-o colecție, specificat de un id.

at collection.at(index)

Adaugă un model la sfârșitul colecției.

pop collection.pop([options])

Șterge și înlocuiește ultimul model dintr-o colecție.

unshift collection.unshift(model, [options])

Adaugă un model la începutul colecției.

shift collection.shift([options])

Șterge și înlocuiește primul model dintr-o colecție.

comparator collection.comparator

Dacă definiți un comparator, acesta va fi folosit pentru a menține colecția în ordinea sortată.

sort collection.sort([options])

Forțează o colecție să se resorteze singură.

pluck collection.pluck(attribute)

Smulge un atribut din fiecare model din colecție.

where collection.where(attributes)

Întoarce o matrice a tuturor modelelor dintr-o colecție care se potrivesc cu atributele trecute.

url collection.url or collection.url()

Setează proprietatea url (sau funcția), pe o colecție care face legătura locației sale pe server.

clone collection.clone()

Returnează o nouă instanță a colecției cu o listă identică de modele.

fetch collection.fetch([options])

Adună un set prestabilit de modele pentru această colecție de la server și le setează colecției atunci când ajung.

create collection.create(attributes, [options])

Crează o nouă instanță a unui model într-o colecție.

1.4.4. Backbone.View

Un view este folosit pentru a afișa informația din interiorul modelului. Mai mult decât atât, într-un view avem posibilitatea de a intercepta anumite evenimente precum: click, keydown, keyup.

extend

Backbone.View.extend(properties, [classProperties])

constructor/initialize

new View([options])

el

view.el

$el

view.$el

setElement

view.setElement(element)

attributes

view.attributes

$(jQuery)

view.$(selector)

template

view.template([data])

render

view.render()

remove

view.remove()

delegateEvents

delegateEvents([events])

undelegateEvents

undelegateEvents()

1.5. Twitter Bootstrap

Bootstrap este un framework pentru design HTML/CSS și Javascript prin utilizarea unor funcționalități din jQuery. Este un framework care are rolul de a oferi elementele de care este nevoie pentru a obține un produs finisat într-un timp scurt. El a pornit ca un proiect open-source, inițiat de echipa de dezvoltare de la Twitter, a prins foarte repede în mediul online, dezvoltându-se pe mai multe direcții. În același timp librăria a declanșat dezvoltarea unor terțe librării și extensii care au ca scop completarea și rafinarea unui pachet întreg de resurse necesare în jurul acestui framework. Twitter Bootstrap are deja scrisă o foaie de stil CSS pentru utilizatori.

1.5.1. Ce oferă Bootstrap?

Conform punctului nr. [2] din bibliografie, dar și conform titlurilor bibliografice nr. [3] și [8] din lista bibliografică, am extras elementele de bază referitoare la Bootstrap:

Suport device-uri mobile: de când cu Bootstrap 3, oferă suport pentru acestea prin crearea de layout-uri responsive în funcție de device-ul care îl accesează.

Browser suport: este suportat de toate browserele populare.

Ușor de folosit: poți începe să lucrezi cu bootstrap doar cu cunoștințe de HTML și CSS; de asemenea site-ul oficial Bootstrap oferă o documentație bună.

Design receptiv: CSS-ul receptiv al lui Bootstrap se ajustează la Desktop, Tablete și Mobile.

Oferă utilizatorilor o soluție curată și uniformă pentru construirea interfețelor.

Conține componente built-in frumoase și funcționale ușor de customizat.

Acesta prevede, de asemenea, personalizare bazată pe web.

Și cel mai bun din toate, este o sursă deschisă.

Pachetul Bootstrap include:

Schelet: Bootstrap oferă o structură basic cu sistem grid, stiluri de link, background.

CSS: Bootstrap vine cu setările CSS globale și cu elemente fundamentale HTML stilizate și îmbunatățite cu clase extensibile.

Componente: Bootstrap conține multe componente reutilizabile construite pentru a oferi iconografie, dropdowns, navigație, alerte, popovers și mult mai mult.

Plugin-uri JavaScript :Bootstrap conține foarte multe plugin-uri JQuery personalizate.

Customizare: Putem customiza componetele Bootstrap, variabilele LESS și plugin-uri JQuery pentru a obține propria noastră versiune.

Ca urmare a succesului și popularității câștigate de acest framework html/css au apărut comunități și pagini web cu scop declarat de a oferi (gratis sau comercial), pachete de interfețe utilizator complete și gata de integrat în aplicații din diverse domenii.

1.5.2. Stiluri

Bootstrap are integrate mai multe stiluri predefinite cum ar fi aspectul tabelelor, butoanelor, panourilor de logare, etc. Datorită acestui lucru munca utilizatorilor este redusă deoarece nu mai trebuie să programăm totul de la zero. Bootstrap ne oferă posibilitatea de a modifica stilurile originale, dacă dorim, sau le putem folosi așa cum sunt. În figura 1.7. putem observa exemple de butoane, tabele și panouri de logare.

1.5.3. Utilizare bootstrap

Coloane

Bootstrap este axat pe un sistem grilă (Grid System) . Sistemul predefinit are 12 coloane care generează un recipient de 940 pixeli lățime dacă nu folosim css-ul responsive și intre 724px și 1170px lățime dacă îl folosim .

Dacă avem o rezoluție a dispozitivului mai mică de 767px atunci coloanele se vor alinia una sub cealaltă și își vor lua dimensiunile în funcție de dimensiunile dispozitivului.

Pentru crearea coloanelor în Bootstrap ne putem folosi de funcția .row. Vom lua un exemplu în care vom avea două div-uri care ocupă câte patru coloane fiecare .

În div-ul al doilea avem loc și putem muta div-ul roșu maxim patru coloane spre dreapta, în exemplul nostru îl vom muta două coloane spre dreapta . Pentru a putea face acest lucru trebuie să adăugăm clasa .offset după clasa .span4.

Pentru redimensionarea automată a coloanelor în funcție de lățimea ecranului folosim clasa .row-fluid în locul clasei .row.

Machetă

Pentru a centra toate coloanele și tot conținutul într-o pagină folosim un div cu clasa .container, iar pentru a putea transforma layout-ul într-unul fluid adugăm clasa .container-fluid.

O pagină Responsive este o pagina ce se adaptează la toate rezoluțiile.

Texte

Pentru alinierea textelor, Bootstrap ne furnizează trei clase diferite:

.text-left : aliniază text-ul la stânga

.text-center : centreză text-ul

.text-right : aliniază text-ul la dreapta

Pentru culori asupra textelor avem următoarele clase:

muted : gri

text-warning: galben

text-error : roșu

text-info : albastru

text-succes : verde

Liste

Listele sunt foarte utile mai ales când dorim să creăm o bară de meniu. Pot fi utilizate două clase, și anume .unstyled și .inline . Când folosim cele două clase împreună ne va dispune lista pe același rând. Aplicând cele două clase, obținem:

Rezultatul obținut va fi: Home About Resource

Pentru a crea tabele în Bootstrap avem la dispoziție câteva clase pentru a-l înfrumuseța. Clasa principală pentru a-l transforma într-un adevărat tabel este table.

Capitolul 2. Baze conceptuale ale lucrării

2.1. Scurtă descriere a aplicației

Doresc să evidențíez contribuțía personală în ceea ce privește aplicația realizată în scopul aplicării noțiunilor teoretice expuse în capitolele anterioare. Aplicația web CinemaWorld este destinată tuturor utilizatorilor de internet, în special celor pasionați de filme. Prin intermediul ei utilizatorii pot căuta și obține informații dintr-o gamă largă de filme.

Prima pagină a aplicatiei este formată dintr-un navbar în partea de sus a paginii cu butoanele Add Movie , Search, ,About si Resources. Pagina home conține o clasă header, o clasă container, două clase row, dintre care una carousel și una content, în care avem dispuse filmele și o clasă footer, în care avem numele autorului aplicației.

În figura 2.1. avem o schemă a sistemului în care funcționează aplicația.

2.2. Interfața paginii de acces

Când accesăm serverul prin comanda http://localhost/CinemaWorlds , severul va trimite fișierul de bază, adică prima pagină a site-ului, și anume index.php, ce va fi afișat în browser.

2.3 Photoshop

Prin intermediul photoshopului am reușit să-mi personalizez o imagine pentru implementarea background-ul paginii web.

CAPITOLUL 3. Date inițiale în elaboarea aplicației

Având la bază noțiunile din titlurile bibliografice nr. [10] și [11], am scris codul pentru aplicația web.

Am folosit programul XAMPP, care a fost creat pentru a pune la dispoziția dezvoltatorilor un instrument eficient de testare a diferitelor aplicatii in dezvltare. Odată instalat pe calculatorul propriu, pachetul de aplicații va face ca acesta să aibă comportamentul unui server, permițând testarea aplicațiilor scrise, motiv pentru care am decis să-l folosesc.

Pentru implementarea metodelor REST în aplicație am folosit framework-ul Slim. Am folosit acest framework pentru comunicarea cu server-ul. Codul folosit pentru implementarea metodelor REST este următorul:

Pentru a da structură aplicației am folosit Backbone.js, care este un MVC (Model View Controller). Backbone.js oferă structură aplicațiilor prin folosirea events, models, collections și views conectate la un API cu o interfață RESTful JSON. Pentru a salva și șterge filme din pagina MovieView am folosit codul de mai jos.

Pentru interfața grafică am utilizat framework-ul Bootstrap. Pentru designul header-ului aplicației am folosit codul următor:

CAPITOLUL 4. UTILIZAREA APLICAȚIEI

În acest capitol voi prezenta modul de utilizare al aplicației pe care am realizat-o și rezultatele contribuției personale la această lucrare. Voi expune interfețele sale în toate situațiile posibile. Cum este o aplicație, accesul web la ea se face cu un program browser web (Chrome, Mozilla Firefox, Opera, Internet Explorer). Vom începe cu prima pagină din browser.

Pe această pagină, utilizatorul poate verifica toate filmele din baza proprie de date, dispuse pe trei pagini. Dacă selectăm primul film, ni se va deschide pagina ca în imaginea de mai sus . În această pagină avem detalii despre film, precum genul filmului, anul lansării, o scurtă descriere a acțiunii filmului, poza de copertă a filmului și, în plus, utilizatorul are posibilitatea de a vizualiza trailer-ul filmului.

Dacă utilizatorii doresc să caute un film anume sau un film în baza de date a aplicației, pot apela la secțiunea de “search” situată în navbar-ul din partea de sus a paginii.

Se realizează o căutare după titlul filmulu, cum ar fi “Transformers”.

În urma căutării, ne sunt afișate sub forma unei liste toate filmele care conțin cuvântul “Transformers”. Selectăm filmul dorit pentru a accesa pagina din imaginea de mai sus, unde avem informații despre film.

În secțiunea “About”, utilizatorii au posibilitatea să adreseze întrebări sau să lase impresii/ păreri/ opinii/ sugestii cu privire la aplicația web în sine sau orice topic legat de pagina pe care au vizitat-o.

Butonul “Resources” din navbar este de tip drop-down și conține link-uri către tehnologiile cu ajutorul cărora a fost creată aplicația (Bootstrap, Js, W3schools) .

Așadar, dupa toate cele prezentate anterior, am expus modul de utilizare al aplicației implementate, împreună cu interfețele sale și toate operațiile ce pot fi realizate fie de utilizatori, fie de administratorul paginii web.

Adăugarea de filme se face prin apăsarea butonului “Add Movie” din navbar, care deschide o alta pagină ce oferă posibilitatea administratorului să introducă datele unui nou film. Vom crea un film numit test, pe care apoi îl vom șterge. Aceste operații sunt prezentate în următoarele două imagini de mai jos.

După ce se realizează introducerea informațiilor despre film în spațiile corespunzătoare, datele vor fi salvate folosind butonul “Save”.

După salvarea filmului el va fi introdus în baza de date și va fi valabil în lista filmelor după cum putem observă în cea de-a două imagine:

Iar încă cazul în care dorim să ștergem un film din listă, putem accesa butonul "Delete", după care va afișa confirmarea ștergerii filmului printr-un mesaj check box"Movie deleted succesfully"

CONCLUZII

Pe parcursul realizării proiectului, s-a elaborat documentația și s-a implementat aplicația în concordanță cu noțiunile teoretice.. Documentația cuprinde descrierea domeniului de aplicare a proiectului, prin prezentarea avantajelor și facilităților pe care le aduce, importanța și necesitatea unei aplicații precum CinemaWorld asupra oricărui tip de utilizator. Studiul teoretic cuprinde o prezentare a tehnologiilor și a tehnicilor de programare folosite în dezvoltarea aplicației. În documentație se expun detalii asupra modului de implementare, soluțiilor folosite și a modului de utilizare a aplicatiei.

Aplicația a fost realizată în totalitate, iar funcționarea sa a fost testată în conformitate cu cerințele inițiale.

Această versiunea a aplicației CinemaWorld poate fi considerată prima versiune a web site-ului. Prin adăugarea anumitor facilități aplicației ea poate fi tranformată chiar și într-o sursă de venit.

Următorul pas în dezvoltarea aplicației este integrarea media streaming-ului în aplicație având ca exemplu popcorntime.io și plex.tv (Plex Media Server).

BIBLIOGRAFIE

[1] Backbone. Preluat de pe : http://backbonejs.org

[2] Bootstrap. Preluat de pe : http://evyned.com/ro

[3] Bootstrap. Preluat de pe: http://www.todaysoftmag.ro/article/258/twitter-bootstrap-in-aplicatii-web

[4] REST. Preluat de pe http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

[5] Slim. Preluat de pe : http://slimframework.com

[6] HTTP. Preluat de pe: https://www.ietf.org/

[7] HTTP. Preluat de pe : https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html

[8] Twitter Bootstrap. Preluat de pe : http://getbootstrap.com

[9] Fielding, R. T. (2000). Architectural Styles and the Design of Network Based Software Architectures. California.

[10] Gugoiu, T. (2009). HTML, XHTML, CSS și XML prin exemple. București: Teora.

[11] Meloni, J. C. (2005). Învață singur PHP, MySQL și Apache. București: Corint.

[12] Vladutiu, M. (2012). Computer Arithmetic.Algorithms and Hardware Implementations. SUA: Springer

[13] Vladutiu, Mircea; Udrescu, Mihai. Network Fidelity: A Metric to Quantify the Similarity and Realism of Complex Networks. 3rd IEEE International Conference on Cloud and Green Computing (CGC), 2013

[14] Vladutiu, Mircea; Opritoiu, Flavius; Prodan, Lucian; Mezo, Patrik. DMail: Distributed mailing system based on the collaboration between traditional and Peer-to-Peer mailing architectures. Singapore: 1st International Conference on Information Engineering, 2012

[15] Vladutiu, Mircea; Udrescu, Mihai; Iovanovici, Alexandru; Topirceanu, Alexandru. Design space exploration for optimizing wireless sensor networks using social network analysis. 18th International Conference on System Theory, Control and Computing, 2014

[16] Popescu, D. E; Lonea A.M; Tianfield, H. Identity Management for Cloud Computing. Springer-Verlag, 2012