Dezvoltarea Unui Portal Pentru Susținerea Fermelor Agricole Folosind Arhitectura Rest

[NUME_REDACTAT] tabele

Listă figuri

[NUME_REDACTAT] 1 [NUME_REDACTAT] 2 Serviciile web – stadiul actual

2.1 [NUME_REDACTAT] [NUME_REDACTAT] (SOAP)

2.2 REpresentational [NUME_REDACTAT] (REST)

2.3 SOAP sau REST

2.3.1 Care este mai bun?

2.3.2 Despre tranzactii

2.3.3 Despre interoperabilitate

2.3.4 REST pentru aplicatii pe Internet si SOAP pentru aplicatii enterprise?

Capitolul 3 Literatura de specilitate

Capitolul 4 Aplicatii similare

Capitolul 5 Implementarea arhitecturii REST

5.1 Prezentarea generală – SmartAgro

5.1.1 Scopul didactic

5.1.2 Scopul functional

5.2 Mod de implementare

5.3 Modelul de date

5.4 Web API

5.4.1 Arhitectura ASP.NET Web API

5.4.2 Mode de apelare

5.4.3 SmartAgro API

5.5 Persistenta datelor

5.6 Aplicatia de client web

5.6.1 Descrierea functionalitatilor

5.6.2 Modul de implementare

5.7 Aplicatia pentru dispozitive mobile

5.7.1 Descrierea functionalitatilor

5.7.2 Modul de implementare

Capitolul 6 [NUME_REDACTAT]

Listă tabele

Listă figuri

[NUME_REDACTAT] 1 [NUME_REDACTAT] 2 Serviciile web – stadiul actual

2.1 [NUME_REDACTAT] [NUME_REDACTAT] (SOAP)

2.2 REpresentational [NUME_REDACTAT] (REST)

2.3 SOAP sau REST

2.3.1 Care este mai bun?

2.3.2 Despre tranzactii

2.3.3 Despre interoperabilitate

2.3.4 REST pentru aplicatii pe Internet si SOAP pentru aplicatii enterprise?

Capitolul 3 Literatura de specilitate

Capitolul 4 Aplicatii similare

Capitolul 5 Implementarea arhitecturii REST

5.1 Prezentarea generală – SmartAgro

5.1.1 Scopul didactic

5.1.2 Scopul functional

5.2 Mod de implementare

5.3 Modelul de date

5.4 Web API

5.4.1 Arhitectura ASP.NET Web API

5.4.2 Mode de apelare

5.4.3 SmartAgro API

5.5 Persistenta datelor

5.6 Aplicatia de client web

5.6.1 Descrierea functionalitatilor

5.6.2 Modul de implementare

5.7 Aplicatia pentru dispozitive mobile

5.7.1 Descrierea functionalitatilor

5.7.2 Modul de implementare

Capitolul 6 [NUME_REDACTAT] tabele

Tabelul 1 – Operații REST în paralel cu CRUD și Operatorii SQL 13

Tabelul 2 – Comparație intre componentele disponibile 17

Tabelul 3 – Model înregistrare utilizator 23

Tabelul 4 – Obiectul CropModel = modelul culturii 25

Tabelul 5 – Model ofertă cultură 25

Tabelul 6 – Obiect UpdateModel ( actualizare cultură) 26

Tabelul 7 – Obiectul CropGridItemModel (rand tabel ) 27

Tabelul 8 – Obiectul CropFilterModel 27

Tabelul 9 – Obiectul GeolocationModel 27

Tabelul 10 – Serviciul pentru manipualrea culturilor 33

Tabelul 11 – Serviciul pentru oferte 33

Listă figuri

Figura 1- Componentele aplicatiei 17

Figura 2 – Legatura intre obiecte 22

Figura 3 – Asocierea conceptelor HTTP la elementele ASP.NET Web API 29

[NUME_REDACTAT] unui studiu in asupra tehnologiilor actuale in domeniul serviciilor web.

Lucrarea de fata reprezinta dezvoltarea unei aplicatii pe baza rezultatului studiului folosind arhitectura REST. Scopul principal al lucrarii este prezentarea principalelor moduri de implementare si utilizare a acestui tip de servicii de catre mai multe dispozitive: client web, aplicatie Android.

[NUME_REDACTAT] web sunt o categorie de soluții web utilizate în diverse industrii, cum ar fi serviciile bancare, cumpărături online, sau de comunicații. Serviciile web poate fi descrise pur și simplu ca oricare alte servicii oferite pe Web. De exemplu, într-o aplicație web de prognoza meteo, un utilizator deschide site (client) de informatii pentru vreme vreme și introduce date (de exemplu, cod poștal), serverul site-ul procesează datele și trimite răspunsul, în acest caz, o prognoză meteo.

Un serviciu Web este alcătuit în principal dintr-un server și un client. Serverul oferă clienților serviciile definite prin intermediul internetului. Acesti clienții pot fi de diferite tipuri: aplicatii tipice de accesarea paginilor pe internet: [NUME_REDACTAT], Chorme, Firefox sau aplicatii server-client concepute in diverse medii de dezvoltare, aplicatii pe diverse dispozitive: telefoane inteligente, televizoare inteligente sau pe dispozitive integrate. În funcție de asupra modului în care serviciul a fost conceput, clientii vor avea fie un necesar minim de cod de funcționare, sau in unele cazuri chiar deloc.

O astfel de grupare de servicii oferite de un server constituie un API (application programming interface). Acesta reprezinta o modalitate de a accesa datele intr-un sistem inchis. Acesta ofera programatorilor posibilitatea de a construii aplicatii folosind date si servicii din surse externe. Cateva exemple celebre sunt:

[NUME_REDACTAT] API: ofera posibilitatea de a integra, a manipula si a folosi hartile oferite de google in multe tipuri de aplicatii.

Facebook API, Twiter API: dupa acordul utilizatorilor, aplicatiile ce folosesc aceste servicii pot accesa sau pot publica diverse informatii pe site-urile de socializare.

RCSB [NUME_REDACTAT] Bank, GenBank: pun la dispozitie prin intermediul serviciilor date cumulate de-a lungul anilor de diversi experti.

Uneori, termenul de "serviciu web" este confundat cu termenul de "website." O importantă distincție între cele două este că serviciul web nu oferă nici o interfață grafică pentru utilizator, asa cum o fac site-urile. Un site și serviciu Web sunt doua entități total diferite. Un site web este o colecție de pagini web și o pagină web poate conține mai multe servicii web. De exemplu, o singură pagină Web poate fi folosit pentru a asculta muzică, cumpărături, și accesarea vreme, atunci când serviciile web aferente sunt construite în pagina.

O altă funcție a serviciilor Web este de a conecta programe de soft între ele peste puncte îndepărtate de pe Internet, care transportă mai bine mai eficient și mai ieftin cantități mari de date. Software-ul timpuriu rula pe un singur calulator, folosind datele locale (încorporate). Mai târziu, odată cu apariția de distribuit și de calcul client-server, datele au fost partajate pe diferite computere care rulează pe platforme diferite. De asemenea, serviciile web sunt un tip de calcul distribuit, dezvoltat pentru a oferi servicii prin Internet. "Serviciile web lucreaza la un nivel de abstractizare similar cu cel al Internetului și sunt capabile de a interconecta orice sistem de operare, platforme hardware, sau limbaj de programare, la fel cum o face internetul" [Aldea]. Servicii web pot împarti resursele, logica, și date printr-o rețea.

[NUME_REDACTAT] [NUME_REDACTAT] (W3C) caracterizează un serviciu Web ca un " sistem software conceput pentru a sprijini interacțiunea interoperabilă mașină-la-mașină printr-o rețea "[Boot 04]. Cele mai multe site-uri interacționează cu servicii web multiple fie individual sau fie în mod concertat, în funcție de cerințele de business. Luați în considerare un site de cumpărături, funcționalități, cum ar fi adăugarea de elemente la un coș, procesarea acestora, verificarea, și de a face plata poate fi dezvoltat ca diferite servicii Web. Pe un astfel de site, aceste servicii web integrate comunică unul cu celălalt, pentru a oferi o experiență mai plăcută la cumpărături utilizatorului.

[NUME_REDACTAT] Language (XML) este forma cea mai comună pentru schimbul de date între serviciile Web. Aplicatii bazate pe servicii Web poat coordona multiple schimburi de mesaje, folosind documente XML standardizate. Astfel, un serviciu Web poate fi, de asemenea, caracterizată ca o colecție de standarde XML bazate electronice care permit comunicare și interacțiune independent de platforme informatice sau specifice tehnologii utilizate de către părți comunicante.

Dar una dintre cele mai mari plângeri legate de XML este faptul că este prea detaliat, ofera un set de date prea mare care consumă multă lățime de bandă. Este, de asemenea, mult mai strict decât multi programatori iși doresc și având în vedere ca este compus din mai multe spații de nume diferite, nu este o potrivire ideală pentru cele mai multe modele de programare. Ca urmare a acestui fapt, analiză XML poate fi destul de greoaie mai ales în interiorul unui browser. Un format popular, care este în căutarea pentru a depăși atât de aceste probleme și este acum formatul de serializare preferat pentru aplicații AJAX este JSON (JavaScript [NUME_REDACTAT]). Este foarte simplu de analizat și transformat in obiecte JavaScript, acesta este, de asemenea, un format sigurt. Este, de asemenea, un format mai "dinamic" și rezistent decât XML ceea ce înseamnă că adăugarea de elemente noi sau modificarea celor existente nu se va deranja rutina de-serializarea, deoarece nu există nici o specificație oficială formatare lucru care aduce atât și avantaje căt și dezavantaje. Din păcate, chiar dacă este un format mai mic, mai simplu este mai lent in procesul de serializare decât XML.

Așa cum se arată în figura 1, serviciul web cuprinde toate logica și toate datele și oferă o modalitate standard de interfață între sisteme. Ele prezintă o modalitate standard de programe software, cum ar fi SGBD, și platforme, cum ar fi. NET, J2EE să interacționeze cu rețeaua. O interfață de serviciu Web primește un mesaj XML dintr-un mediu de rețea și transformă mesajul într-un format înțeles de către sistemele de interfațare. Punerea în aplicare a acestei logici de transformare a mesajului XML pot fi creat folosind orice limbaj de programare.

Tehnologii de sistemes distribuite, cum ar fi Corba, Orbacus, și Java RMI au fost dezvoltate pentru a satisface nevoile de calcul distribuit, dar lipsite de interoperabilitate. Pentru a rezolva această lipsa de interoperabilitate, W3C a dezvoltat [NUME_REDACTAT] [NUME_REDACTAT] (SOAP), care utiliza standarde industriale, cum ar fi XML și HTTP ([NUME_REDACTAT] [NUME_REDACTAT]), pentru a facilita schimburile între aplicațiile software, independent de platforma pe care au fost dezvoltate. SOAP este o specificație tehnologică dezvoltată pentru a ajuta interfațarea de servicii web cu alte sisteme.

O altă abordare concurente care sprijină dezvoltarea de interfețe de servicii Web este [NUME_REDACTAT] Transfer (REST). REST este un set de principii arhitecturale pentru dezvoltarea de aplicații Web. Principiile REST se concentreze pe modul în care resursele sunt abordate și transferat in HTTP, de o gamă largă de aplicații de client scrise în limbi diferite [Rodriguez 08].

Deși SOAP si REST sunt ambele metode de a construi un serviciu Web, ele diferă în modul de prelucrare a datelor și de a oferii servicii. SOAP este un protocol, în timp ce restul este arhitectura. Prin urmare, nu este adecvat să se compare aceste două tehnologii, aceasta fiind o greșeală comună.

Serviciile web – stadiul actual

[NUME_REDACTAT] [NUME_REDACTAT] (SOAP)

SOAP, inițial definit ca un simplu protocol de acces al obiect, este un protocol pentru schimbul de informații structurate în punerea în aplicare a serviciilor Web în rețele de calculatoare [SOAP11]. WSDL ([NUME_REDACTAT] [NUME_REDACTAT]) este utilizat împreună cu SOAP pentru a face mesajele disponibile pe Web prin intermediul serviciilor web. Într-un context în vrac, săpun, în concert cu WSDL este numit de servicii Web SOAP. Fără SOAP, serviciile Web nu sunt în măsură să treacă sisteme de operare și platforme, și de multe ori lipsa de interoperabilitate. SOAP a fost conceput pentru a acoperi această lacună, ceea ce face mai ușor pentru dezvoltator pentru a proiecta un program de web independent de aceste limitări.

SOAP are in prezent la bază protocolul HTTP, dar se pot utiliza și alte protocoale pentru transferul de date. Microsoft a fost primul care a început dezvolatea SOAP, și mai târziu Ariba, [NUME_REDACTAT], Compaq, DevelopMentor, HP, IBM, Lotus, SAP, și UserLand au început să contribuie la dezvoltarea acestuia. În istoria calcualtoarelor personale, prelucrarea datelor a constat dintr-un PC folosind aplicatii simple care se bazau pe resurse locale. Dezvoltarea în domeniul retelelor a introdus treptat concepte, cum ar fi LAN ([NUME_REDACTAT] Network), MAN ([NUME_REDACTAT] Network), și WAN ([NUME_REDACTAT] Network), care permit calculatoare aflate fizic în locații diferite să comunice. Protocoale de servicii web sunt concepute pentru a facilita transferul de date pe Internet. Cele mai multe dintre protocoalele folosite de serviciile Web fac computerele să funcționeze pe platforme, tehnologie, precum și sisteme de operare similare. Necesitatea unui protocol care a fost independent de aceste constrângeri a dat naștere la protocolul SOAP, care utilizează XML pentru a comunica mesaje peste nivelul transport.

SOAP este destinat să furnizeze un nivel minim de transport, peste care alte interacțiuni și protocoalele mai complicate pot fi construite [Newcomer 02]. SOAP prevede reguli de codare a datelor și de multe ori depinde de înțelegerea destinatarului. Procesul SOAP ce folosește WSDL este ilustrat în figura 2. Un client SOAP poate fi proiectat prin cunoașterea adresa URL si portul serverului. Acest lucru mai târziu a devenit mai ușor cu apariția WSDL și suportul IDE ([NUME_REDACTAT] Environment). WSDL este un format XML pentru a descrie servicii de rețea ca un set de mesaje. "WSDL este extensibil pentru a permite descrierea mesajelor, indiferent de formatul mesajelor sau protocoalul de rețea folosit în comunicație" [Christensen 01].

Așa cum se vede în figura 2, programele și aplicațiile site-ului 1 sunt legate de WSDL și expuse pe internet ca un serviciu Web utilizând SOAP. Site-ul 1 este conectat la site-ul 2 prin SOAP. Procesoarele SOAP ale fiecarui site procesează mesajele SOAP. Figura 2 poate fi, de asemenea, văzută ca un server și client ce comunica unul cu altul, folosind protocolul SOAP. Un program al site-ului 1 este proiectat folosind J2EE și transformat într-un serviciu Web utilizând SOAP; serviciile oferite de program sunt expuse pe internet. Procesorul SOAP de la site-ul 2 va prelucra mesajele transmise prin site-ul 1 și va face mesajul accesibil pentru programele sau aplicațiile care rulează pe site-ul 2.

Întregul proces poate fi rezumat ca un model de cerere – răspuns client / server. Clientul din site-ul 2 trimite cereri la server la site-ul 1, ca un mesaj SOAP. Mesajul prelucrat de la site-ul 1 va trimite mesajul de răspuns a site-ului 2, folosind SOAP. Mesajul SOAP primit de către clientul din site-ul 2 este procesat de către procesorul SOAP și pus la dispoziție programele locale. Astfel, SOAP foloseste nivelul de aplicație ca un nivel de transport. Mulți critici protesta aceasta este un abuz al nivelului de transport. SOAP a fost standardizat oficial de W3C în 2003, pentru a fi utilizat in expunerea datelor, folosind interfețe sau servicii care fac schimb de documente sau transformarea datelor în obiecte, folosind nume de metode și argumente de intrare și de ieșire [Newcomer02]. Mai jos este un exemplu de format tipic mesaj SOAP preluat de la http://www.w3schools.com/:

<?xml version="1.0"?>

<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

…

Message information goes here

…

</soap:Envelope>

Elementul „Envelope” indică început și sfârșitul mesajului. Antetul conține date opționale utile pentru procesareea mesajelor. Corp este format din principalele date XML. În plus pentru a fi independent de HTTP, mesajele SOAP au avantajul unui element atașat pentru a fi utilizat in trimiterea atașamentelor împreună cu mesajul. Elementul de atașare este adesea considerat cel mai bun pentru servicii Web care se ocupă cu fișiere atașate. SOAP oferă astfel un grad bun de securitate și fiabilitate incât cele mai multe servicii bancare au fost proiectate folosind SOAP.

REpresentational [NUME_REDACTAT] (REST)

REST este o arhitectură pentru dezvoltarea de servicii Web. REST încearcă să imite arhitectura care o utilizează HTTP sau alte protocoale similare, prin constrângerea interfaței la un set de operații standard bine-cunoscute (de exemplu, GET, PUT, POST, și DELETE pentru HTTP). Aici, se pune accent mai degrabă pe interactiunea cu resurse ce conțin stari determinate, decât pe mesaje sau operații. "Arhitectura REST este conceput pentru a arăta că protocoul HTTP existent este suficient pentru a construi un serviciu Web și pentru a arăta scalabilității sale" [REST11].

[NUME_REDACTAT], care este, de asemenea, unul dintre principalii autori ai HTTP-ului, în teza sa de doctorat [Fielding 00], "Stiluri de arhitectură și design de arhitecturi de software bazată pe rețele" definește un set de principii arhitecturale pentru Web numit REST. Principii arhitecturale REST pot fi utilizate pentru proiectarea de servicii Web. REST se concentrează asupra resurselor de sistem, inclusiv modul în care starile resurselor sunt adresate și transferate prin HTTP [Rodriguez 08].

Ideea principala care stă la baza arhitecturii REST a fost mai degrabă utilizarea protocoluilui HTTP bine dezvoltat pentru transferul de date între mașini, decât folosind un protocol care funcționează pe stiva de sus a protocolului HTTP pentru transferul de mesaje. O aplicație proiectată în conformitate cu principiile REST ar folosi mai degrabă HTTP pentru a efectua apeluri între mașini, decât bazându-se pe mecanisme complexe, cum ar fi CORBA ([NUME_REDACTAT] comun [NUME_REDACTAT]), RPC ([NUME_REDACTAT] Call), sau SOAP. Prin urmare, cererile REST utiliza funcțiile de cerere HTTP pentru a publica date, citit de date, și șterge datele, astfel folosind funcționalitatea completă a HTTP operațiuni CRUD (Create, Read, Update, si Delete). REST poate rula, de asemenea, pe HTTPS, care presupune transmiterea securizată a datelor.

Operațiunile de CRUD, în colaborare cu funcții HTTP REST și operațiunile SQL relevante sunt prezentate în Tabelul 1.

Tabelul 1 – Operații REST în paralel cu cei CRUD și Operatorii SQL

Spre deosebire de SOAP, REST nu este un protocol. Aplicarea principiilor REST pentru servicii Web necesită protocoale cum ar fi HTTP. Orice programator sau de utilizator ce cunoaste protocolul HTTP ar trebui să găsească ușor de înțeles și aplicat principiile REST. Termenul " RESTful " este ca un limbaj "orientat pe obiect", o aplicație care poate fi concepută într-un mod orientat pe obiect, dar care nu are arhitectura bazată pe orientată-obiect [Richardson 07].

REST este o arhitectură pentru construirea de servicii Web și un set de principii de design similare cu un model pentru construirea unei case. Acesta este doar un ghid de bază pentru construirea unui serviciu Web, nu un set fix de reguli.

REST vede totul ca o resursă, și în cuvintele Dr. [NUME_REDACTAT], "o resursa este ceva care este destul de important pentru a fi referite ca un lucru în sine" [Richardson 07], cum ar fi un fișier stocat într-un calculator, un software , un atribut într-un tabel de baze de date, sau un obiect fizic ca un fruct. Resursele pot fi statice sau dinamice, statice ca o carte, sau dinamic, cum ar fi "vremea" (de exemplu, se schimbă mereu, dar încă mai este o resursă). [NUME_REDACTAT] statice, de exemplu, nu se schimbă dacă sunt resolicitate de către utilizatori. Paginile web dinamice s-ar putea schimba și, spre deosebire de cele statice, nu sunt cacheable.

Fiecare resursă trebuie să aibă cel puțin un URI ([NUME_REDACTAT] Identifier), sa o să-l reprezinte. REST se referă la el ca reprezentare a resurselor. URI este adresa Web a resurselor, și face resursele disponibile on-line. O resursă poate fi accesat / referite de propriul URI. Adresabilitate este o modalitate de a reprezenta o resursa on-line: " o aplicație adresabil expune teoretic un URI pentru fiecare bucată de informații pe care ar putea sa o servească" [Richardson07]. O cerere ar trebui să fie făcută în mod corespunzător pentru a o face disponibilă online. O casă și adresa acesteia este ca o resursă online și URL-ul sau. O casa poate fi localizat prin adresa de pe stradă, iar în același mod o resursă ar trebui să fie accesată pentru a fi disponibilă online. Luați spre exemplu o căutarea on-line pe un motor de căutare. Motorul de cautare este adresabil și HTTP este adresabila. În cazul în care resursa pe care o căutați este adresabila, motorul de căutare se va folosi.

„Statelessness” (fară stare) este un alt concept de REST; acesta înseamnă că toate cererile HTTP sunt independente una de alta. Fiecare cerere HTTP de la client trebuie să conțină toate informațiile de pe server, astfel încât serverul nu trebuie să păstreze informațiile de stare de la cererile clienților. Definirea adresabilității în termeni de „statelessness”, toate stările posibile ale serverului sunt, de asemenea, resurse și ar trebui să fie reprezentate de un URI.

Google este unul dintre primele servicii web care au urmarit arhitecutra REST. [NUME_REDACTAT] este complet construit pe principiul REST, așa cum este si motorul de căutare Google. Într-un exemplu real REST folosind motorul de căutare Google, căutare dupa București va afișa unele rezultate. Pagina de rezultate va avea o adresă. Adresa celei de-a doua pagini de rezultate va fi diferită de prima. Această adresă poate fi copiată, stocată și accesată mai târziu. Nu va mai fi nevoie pentru a merge la pagina de web Google pentru a căuta București și a face clic pentru a doua pagina de rezultate. Acesta este un exemplu de un serviciu Web în urma conceputlui „statelessness”.

Un serviciu Web fara stare are și alte avantaje, cum ar fi utilizarea de serverelor echilibrate in sarcini (load-balanced) pentru performanță. Din moment ce nici o cerere la serviciul Web nu este dependentă de alta, și deoarece clientul poartă toate informațiile necesare, nu este nevoie de coordonare între mai multe servere. Acest lucru elimină timpul de procesare pentru servere pentru operațiunile anterioare de date / de proces.

Fiecare stare a unei resurse se numeste reprezentare. O resursă poate avea mai multe stări și fiecare stare poate fi reprezentat în mod individual. Stările unei resurse sunt similare cu statele materiei: lichid, gaz, sau solid. Luați în considerare exemplul un chioșc de închiriere DVD: putem căuta disponibilitatea unui DVD, la un anumit chioșc on-line. Căutarea va returna un DVD ca: disponibil, sau care urmază sa fie in stoc, sau deja inchiriat, astfel încât aceeași resursă, DVD-ul, este reprezentat în mai multe stari. Acest lucru ilustrează importanța cuvântului cheie "Reprezentanța", în REST.

[NUME_REDACTAT]. [NUME_REDACTAT] [Fielding 00], există două perspective periodice cu privire la procesul de design arhitectural; unul este de a începe construirea fără nici un plan, sau construirea de la zero, și mai târziu se adaugă componente pentru a se potrivi cerințelor. Cealaltă este de a începe construirea cu un plan de a pune în aplicare toate cerințele. Caracteristicile suplimentare pot fi adăugate mai târziu, fiind adaptate cu caracteristicile existente și finalizarea lor în funcție de cerințele. "Componente REST comunica prin transferarea o reprezentare a unei resurse într-un format de potrivire unul dintre un set evoluție de tipuri de date standard, selectate în mod dinamic în funcție de capacitățile și dorințele beneficiarului și de natura resurselor" [Fielding 00].

Arhitectura REST la nivelul serverului este compusă din:

URL: câmp obligatoriu pentru a avea acces la serviciile web care rulează pe server.

GET: Toate metodele de a obține date de la server; formatele și interfețele serverul sprijină în a accesa detalii de client.

POST: Toate metodele de a adăuga detalii la server; toate interfețele și formatele acceptate de server pentru adăugarea datelor la baza sa de date.

PUT: Toate metodele de actualizare a datelor la server; diferite tipuri de interfețe și formate acceptate de server pentru modificarea datelor în baza de date.

DELETE: Toate metodele pentru ștergerea datelor de la server; diferite tipuri de interfețe și formate acceptate de server pentru modificarea datelor în baza de date.

Având în vedere ușurința de proiectare și flexibilitate în codificare oferite de REST, acesta a devenit treptat popular. Yahoo si eBay au fost primii care folosesc REST pentru proiectarea propriilor servicii web. Lor li s-au s-au alăturat mai târziu firme populare, cum ar fi, Facebook și Twiter, Amazon sau Google.

Exemplu the mesaj in arhitectura REST

POST /ajax/bz HTTP/1.1

Host: www.example.com

Connection: keep-alive

Content-Length: 477

Origin: https://www.example.com

User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) _

Chrome/27.0.1453.116 Safari/537.36

Content-Type: application/x-www-form-urlencoded

Accept: */*

Referer: https://www.example.com/messages/…

Accept-Encoding: gzip,deflate,sdch

Accept-Language: en-GB,en;q=0.8,en-US;q=0.6

Cookie: datr=…

HTTP/1.1 200 OK

Cache-Control: private, no-cache, no-store, must-revalidate

Content-Type: application/x-javascript; charset=utf-8

Expires: Sat, 01 Jan 2000 00:00:00 GMT

Pragma: no-cache

Strict-Transport-Security: max-age=60

Content-Encoding: gzip

Date: Sun, 30 Jun 2013 11:28:31 GMT

Transfer-Encoding: chunked

Connection: keep-alive

…

SOAP sau REST

http://msdn.microsoft.com/en-us/magazine/dd942839.aspx,

Tabelul 2 – Comparație intre componentele disponibile

Care este mai bun?

Despre tranzactii

Despre interoperabilitate

REST pentru aplicatii pe Internet si SOAP pentru aplicatii enterprise?

Literatura de specilitate

Teza de doctorat a lui [NUME_REDACTAT] Fielding, "Stiluri arhitecturale și de design de arhitecturi software rețea bazată pe" este locul unde REST are originea [Fielding 00]. Dr. Fielding a studiat evaluarea de design arhitectural de software de aplicație pe bază de rețea prin utilizarea de principiu de constrângeri arhitecturale și a definit un cadru nou de arhitectura software, demonstrând cât de stiluri pot fi folosite pentru a ghida design arhitectural de software de aplicație bazată pe rețea. Fielding este unul dintre principalii autori din caietul de sarcini HTTP și [NUME_REDACTAT] (WWW), [NUME_REDACTAT] și arhitectural REST modelul său întruchipează toate principiile majore ale WWW. În cuvintele lui Fielding, "motivația pentru dezvoltarea REST a fost de a crea un model arhitectural pentru modul în care ar trebui să funcționeze pe Web, astfel că ar putea servi drept cadru de ghidare pentru standardele [NUME_REDACTAT]" [Fielding 00].

Aplicatii similare

Implementarea arhitecturii REST

Prezentarea generală – SmartAgro

Scopul didactic

Implementarea serviciilor web REST folosind arhitectura Micrososft .NET Web API 2

Demonstrarea conceptului de statelessness si independenta limbajlelor de programare prin consumarea acestor servicii de pe un client web si de o aplicatia Android.

Integrarea serviciilor puse la dispozitie de [NUME_REDACTAT]

Scopul functional

Platforma SmartAgro vine în sprijinul agricultorilor. Se poate observa cum în alte domenii aplicațiile web sau mobil sunt folosite pentru a îmbunătăți eficiența în producție crescând astfel profiturile, iar același lucru poate fi valabil și în agricultură. Deși acest domeniu implică o echipă multidisciplinara, totusi fermierul este omul de baza. Aplicatia se adresează atat agricultorilor cat si celor care sunt interesati de produsele agricole. Fermierul are posibilitatea de gestiune a propriilor culturi proprii iar cumparatorii pot fi tinuti la curent cu evolutia culturilor, pot contacta proprietarii si pot trimite oferte

Platforma este compusa din trei parti principale.

Web API – se ocupa cu managementul datelor introduse de utilizatori si salvarea lor in baza de date

Aplicatia web

Utilizatorii se pot înregistra

Fermierii își pot administra culturiile

Cei interesati de produsele agricole pot vedea culturile, contacta agricultorii si trimite oferte.

Aplicatia pe mobil

Este dedicată special agricultorilor. Pentru că ei nu au mereu la îndemână un calculator, aceștia pot adauga actulizări la propriile culturi direct de pe teren, printr-o poza si o descriere.

Mod de implementare

Modelul de date

Figura 2 – Legatura intre obiecte

In tabelele urmatoare sunt descrise obiectele folosite in aplicatie

Tabelul 2 este folosit la înregistrarea utilizatorului

Tabelul 3 – Model înregistrare utilizator

Tabelul 3 reprezintă obiectul Cultură. Acestea contine atât informații generale căt și informații specifice pentru fiecare faza a culturii:

Pregătire teren

Selecție si plantare semințe

Creșterea culturii

[NUME_REDACTAT] 4 – Obiectul CropModel = modelul culturii

Tabelul 5 – Model ofertă cultură

Tabelul 6 – Obiect UpdateModel ( actualizare cultură)

Tabelul – Obiectul CropGridItemModel (rand tabel )

Tabelul – Obiectul CropFilterModel

Tabelul – Obiectul GeolocationModel

Web API

Arhitectura ASP.NET Web API

Asa cum este specificat in cartea „Pro ASP.NET Web API”, ASP.NET Web API are un design foarte modern si profita de cele mai recente caracteristici ale Framework-ului .NET. Dar la baza, este construit pe un model de proiectare tip filtru și, după cum știm, simplitatea este putere. Această secțiune va revizui designul și arhitectura Web API ASP.NET.

Caracteristici arhitecturale

Echipa API Web ASP.NET a făcut unele decizii importante care au dus la robustețe, modularitate, și testabilitate framework-ului. Unele dintre aceste decizii includ:

Asincron pe tot parcursul: Framework-ul API Web ASP.NET a fost proiectat folosind modelul de programare asincron bazat pe sarcini din partea de sus în jos. Acesta duce la creșterea scalabilității.

S-a renunțat la HttpContext.Current: Deși ASP.NET MVC-a împachetat HttpContext în interiorul HttpContextBase pentru o mai bună testabilitate, ASP.NET Web API duce acest lucru chiar mai departe și stochează toate proprietățile contextuale ale cererii în dicționar Request.Properties. Deși accesarea HttpContext în ASP.NET Web API-ar putea funcționa în continuare, utilizarea de HttpContext.Current este nerecomandată din cauza pierderilor posibile de context în comutarea asyncronă a thread-urilor.

Reproducerea arhitecturii HTTP atat în biblioteca de pe client, precum și în biblioteca de pe server: Acest lucru ajută cu unificarea modelul de programare, precum și ușurința de a efecua teste de integrare.

Abilitatea de a găzdui atât pe ​​IIS (sau server de dezvoltare) și, în orice proces de server nonweb (numit auto-găzduire): Viitoarele versiuni ale ASP.NET Web API va avea capacitatea de a fi găzduit în servere de web personalizate.

Suport deja implementat pentru injectare de dependințe: ASP.NET Web API suportă orice cadru pentru injectare de dependințe personalizat printr-o interfață simplă locație de servicii.

Customizarea serviciilor chiar pentru componente ale framework-ului deja existent: se poate personaliza mai multe elemente de ASP.NET Web API prin implementare proprie.

Testabilitate: ASP.NET Web API a fost proiectat cu testarea în minte. Aproape toate părțile framework-ului sunt testabile.

HttpConfiguration: Contextul API Web ASP.NET este captat și reprezentat în clasa HttpConfiguration. HttpConfiguration este un loc central pentru a defini diferitele aspecte ale runtime-ului și nu are proprietăți statice, făcându-l mai testabile. Proprietăți contextuale importante includ:

[NUME_REDACTAT] de mesaj

Filtre globale

[NUME_REDACTAT] dependențe

Asociere de parametrii

Elemente ASP.NET Web API

ASP.NET Web API a fost construit pentru a mapa modelul de programare web / HTTP pe modelul de programare .NET Framework. Pentru rezolvarea acestor probleme, se folosesc uneori construcții familiare introduse în ASP.NET MVC, cum ar fi Controller, Acțiune, Filtru, etc. Figura 3 prezintă un exemplu de o cerere și asociere construcției HTTP la componentele ASP.NET API Web. Ne vom uita la unele dintre cele mai importante componente ASP.NET API Web astfel încât să ne putem creea o imaginea de ansamblu.

Figura 3 – Asocierea conceptelor HTTP la elementele ASP.NET Web API

[NUME_REDACTAT] framework-ului ASP.NET Web API-ul a fost construit peste rutarea ASP.NET, deși acesta nu a fost cuplat la ea. Se poate vedea în partea de procesare HTTP că HttpControllerDispatcher este motorul pentru trimiterea cererilor catre controlere în funcție de rută. ASP.NET Web API folosește o abordare similară (dar nu la fel) pentru rută definita. Datele rutei sunt apoi utilizate în continuare de către IHttpControllerSelector și HttpActionSelector pentru a găsi controlerul și acțiunea potrivită.

Parametrii si modelul asociat

Parametrii și modelul de legare sunt folosiți pentru a asocia fragmentele URL-ul și parametrii șirului de interogare la parametrii metodelor și proprietăților de modelului. Dacă ați utilizat deja ASP.NET MVC, sunteți familiarizați cu conceptele de asociere. Parametrii și modelu l de asociere în ASP.NET Web API este inspirat de ASP.NET MVC, dar are unele funcționalități suplimentare.

Controlere și acțiuni

Controlere și acțiunile sunt concepte familiare împrumutate de la ASP.NET MVC, deși există câteva diferențe. Controlere ASP.NET API Web trebuie să fie derivat din clasa ApiController.

Mode de apelare

Pentru a exemplifica mai usor modul de apel, am creat un serviciu demonstrativ care folosește cele patru verbe HTTP (GET, POST, PUT, DELETE). ASP.NET web api foloște un mecanism de interpretare al URL-ului pentru a selecta Controllerul si Acțiunea dorită. In aceasta aplicație am stabilit conveția ca pentru serviciile web definesc ruta cu prefixul „api” in fata:

Această confiigurare este setata odată ce aplicația pornește. Serviciul demonstrativ se bazeaza pe cele patru verbe pentru a afisa, adăuga, modifica si șterge dintr-o lista de siruri de caractere. Pentru a apela URL-url specific am folosit programul Fiddler.

Apelul corespunzator verbului GET se face cu ajutorul URL-ului /api/Values. Mecanismul de rutare asociază [NUME_REDACTAT] din Controler.

Raspunsul reprezinta un JSON format din cele trei valori din lista de siruri de caractere:

Similar se poate accesa o singura valoare se foloseste tot vervul GET dar se specifica si id-ul pe care vrem sa-l returnam in URL : api/Values/2

Pentru situația in care dorim să adaugăm ceva in lista se va folosi acelasi url api/Values dar de aceasta dată vom specifica verbul POST, iar in corpul mesajului transmis va fi un JSON de forma:

{ „value” : „value 4”}

În cazul unei modificari al unui term din lista se folosește verbul PUT, și se specifică in URL id-ul de modificat: api/Values/2. La fel ca la POST se specifică în mesaj un JSON cu noua valoare.

Pentru a sterge un obiect din lista se folosește verbul DELETE cu url-ul: api/Values/2

SmartAgro API

Serviciile web sunt implementate folosind arhitectura oferita de cei de la Micrososft, descrisă mai sus. Voi prezenta in continuare fiecare API-ul rezultat, modul de apelare si cateva exemple. Serviciile web sunt integrate intr-um proiect ce respecta arhitectura de design Model-View-Controller. În aceast capitol mă voi concentra doar pe partea de Web API care constituie defapt Controlere.

Mai jos este prezentat modul de acces al unei culturi:

Tabelul – Serviciul pentru manipualrea culturilor

Serviciul pentru manipularea ofertelor culturii.

Tabelul – Serviciul pentru oferte

Persistenta datelor

Aplicatia de client web

Programarea web este foarte departe de ceea ce a fost acum zece ani de zile. Apariția de dispozitive inteligente și adoptarea mai bune tehnici JavaScript și bibliotecile au deschis cale spree o programare pe client foarte vastă, bazându-se din ce ince mia puțin pe server pentru a conduce logica aplicației. Un tip de aplicație web numit [NUME_REDACTAT] Application (SPA), a câștigat o mulțime de popularitate (Gmail este un exemplu celebru de SPA). În acest tip de aplicație, server oferă doar cod static și șabloane HTML și JavaScript iar apoi aplicația începe să se încarce datele apelând serviciile web de pe server folosind Ajax. Toate navigarea și încărcare ulterioară a datelor sunt manipulate fără o cerere completă la server. SPA este utilizat de obicei cu un framework Model-View-Controller de JavaScript, cum ar fi Backbone.js, AngularJS.

ASP.NET Web API a devenit popular intr-un timp foarte scurt în a furniza date pentru aceste tipuri de aplicații. Deoarece HTML este procesat mai degrabă pe client folosind tehnica de șabloane JavaScript, decât pe serverul, ASP.NET Web API este o potrivire pentru furnizarea de date brute. La o examinare mai atentă, vom constata că, în multe cazuri, un API public bine proiectat poate fi folosit ca un furnizor de date pentru SPA. Un astfel de API poate oferi o mulțime de valori care deservesc clienții B2B, precum și diverse dispozitive client și aplicații desktop.

Descrierea functionalitatilor

Modul de implementare

Aplicatia pentru dispozitive mobile

Descrierea functionalitatilor

Modul de implementare

Conculzii