Odprtokodni API Restlet zmanjša delovno obremenitev, povezano z gradnjo in porabo API-jev RESTful v Javi. V tem drugem članku v REST za razvijalce Java Brian Sletten vas seznani z Restletom in si ogleda primer aplikacije pri uvajanju njegovih vmesnikov v vsebnike servletov, ki jih uporabljate danes, hkrati pa se pripravlja na sisteme prihodnosti. Brian na kratko predstavi tudi JSR 311: JAX-RS, prizadevanje podjetja Sun, da integrira API-je RESTful s skladom Java EE.
Razvijalce Jave že dolgo zanima arhitekturni slog REST, vendar le redki še niso prevozili razdalje med znanim svetom predmetov in RESTful svetom virov. Čeprav nam je morda všeč, da lahko storitve RESTful proizvajajo ali uporabljajo drugi jeziki, sovražimo, da moramo podatke pretvarjati v bajtne tokove in iz njih. Sovražimo razmišljati o HTTP pri uporabi orodij, kot je Apache HTTP Client. Hrepeneče gledamo na predmete, ki jih je ustvaril wsdl2java ukaz, ki nam omogoča, da argumente v storitev SOAP prenesemo tako enostavno kot kateri koli klic druge metode, pri čemer podrobnosti klica oddaljene storitve pometemo pod preprogo. Ugotovili smo, da je model strežnika le nekoliko preveč odklopljen od ustvarjenih virov. Dovolj je reči, da medtem ko smo že bili sposoben graditi RESTful storitve iz nič, ni bila prijetna izkušnja.
REST za razvijalce Java
Preberite serijo:
- 1. del: Gre za informacije
- 2. del: Počivališče za utrujene
- 3. del: NetKernel
Politična vprašanja so včasih pomenila tehnične ovire. Številni upravitelji menijo, da so spletne storitve, ki temeljijo na SOAP, predpisani način gradnje storitveno usmerjenih arhitektur (SOA) v Javi EE. To se spreminja s pojavom pomembnih dejavnosti, kot so JSR 311, JAX-RS: Java API za spletne storitve RESTful, o katerih boste izvedeli v tem članku. Če nič drugega, to prizadevanje legitimizira RESTful razvoj v prostoru JEE.
Medtem je prišla pomoč. Z odprtokodnim ogrodjem Restlet se na eleganten način enostavno izognete neprijetnim težavam, ki se lahko pojavijo pri uporabi tradicionalne tehnologije JEE za gradnjo in uporabo storitev RESTful.
Restletove korenine
V prizadevanju za reševanje nekaterih tehničnih težav, povezanih z izvajanjem REST z Javo, je Jérome Louvel, francoski svetovalec za programsko opremo, skušal ustvariti okvir, ki bi zagotovil bolj naravno prileganje. Kot izhodišče je najprej pogledal okolje NetKernel. Kolikor mu je bilo všeč, ni bil povsem primeren za ogrodje, osredotočeno na API, ki ga je želel dati na voljo. Izkušnje pa so pomagale vplivati na njegovo razmišljanje o vrstah stvari, ki jih lahko nudi okolje, usmerjeno v REST. (Naslednji članek v tej seriji bo NetKernel podrobneje raziskal.)
Ko je Louvel delal na svojem ogrodju, je razvil tri cilje:
- Preprosta dejanja bi morala biti preprosta za osnovno uporabo. Privzete nastavitve bi morale delovati z minimalnim naporom, omogočajo pa tudi bolj zapletene konfiguracije.
- Koda, napisana v ta API, mora biti prenosljiva med vsebniki. Čeprav je mogoče sisteme, ki temeljijo na strežniških programih, premikati med vsebnike, kot so Tomcat, Jetty in IBM WebSphere, je imel Louvel v mislih širšo sliko. Specifikacija strežniškega programčka je vezana na HTTP in blokirni V / I model. Želel je, da je njegov API ločljiv od obeh in ga je mogoče namestiti v zabojnike, ki so danes v uporabi. Želel je tudi, da bi bili uporabni z malo truda v nadomestnih in nastajajočih vsebnikih, kot so Grizzly, AsyncWeb in Simple Framework.
- Obogatiti mora ne le strežniško stran, ki proizvaja vmesnike RESTful v Javi, temveč tudi odjemalsko stran. The
HttpURLConnectionclass in Apache HTTP Client sta prenizka, da bi jih lahko neposredno vključili neposredno v večino aplikacij.
S temi cilji se je lotil izdelave API-ja Restlet. Po nekaj letih spreminjanja je API postal stabilen in okoli njega je rasla skupnost. Danes ima jedro API živahno bazo uporabnikov in potekajo pomembne dejavnosti za podporo integraciji z drugimi orodji in pobudami, kot je JAX-RS. (Louvel je zdaj član strokovne skupine JAX-RS.)
Osnove restlet
Osnovni strežnik z API-jem Restlet ne more biti lažji, kot je prikazano v seznamu 1.
Seznam 1. Osnovni strežnik z Restletom
paket net.bosatsu.restlet.basic; uvoz org.restlet.Restlet; import org.restlet.Server; import org.restlet.data.MediaType; uvoz org.restlet.data.Protocol; import org.restlet.data.Request; import org.restlet.data.Response; javni razred SimpleServer {public static void main (String [] args) vrže izjemo {Restlet restlet = new Restlet () {@Override public void handle (Request request, Response response) {response.setEntity ("Pozdravljeni, Java RESTafaries!", MediaType.TEXT_PLAIN); }}; // Izogibajte se konfliktom z drugimi zabojniki Java, ki poslušajo 8080! nov strežnik (Protocol.HTTP, 8182, restlet) .start (); }}Ta aplikacija sicer ne prinaša veliko (razen širjenja dobre volje), vendar kaže dva temeljna načela Restleta. Prvič, preproste stvari so preproste. Vsekakor so možne tudi bolj zapletene dejavnosti, vendar jih zanje skrbite le, kadar je treba. REST-u ne manjka zmožnosti uveljavljanja varnosti, omejitev, dogovarjanja o vsebini ali drugih pomembnih nalog. Te ostajajo večinoma pravokotne dejavnosti, ki se precej razlikujejo od procesa izpolnjevanja API-ja RESTful. Zapletenost polagate po potrebi.
Drugič, koda iz seznama 1 je zasnovana tako, da je prenosljiva med vrstami vsebnikov. Upoštevajte, da ne določa vsebnika. Restletso dejanski viri, ki na koncu odgovorijo na zahteve. Med vsebnikom, ki obdeluje zahtevo, in odzivnikom informacijskega vira ni razlike, kot je to mogoče v modelu strežniškega programčka. Če vnesete kodo v IDE in dodate odvisnosti na org.restlet.jar in com.noelios.restlet.jar arhiv, lahko zaženete aplikacijo in videli boste sporočilo dnevnika, kot je to:
7. december 2008 23:37:32 com.noelios.restlet.http.StreamServerHelper start INFO: Zagon notranjega strežnika HTTP Usmerite brskalnik v // localhost: 8182, in videli bi prijazen pozdrav.
V zakulisju org.restlet.jar vsebuje vse glavne vmesnike za ta API. The com.noelios.restlet.jar vsebuje osnovno izvedbo teh vmesnikov in zagotavlja privzeto zmožnost obdelave HTTP. S tem mehanizmom HTTP ne boste želeli začeti proizvodnje, je pa izjemno primeren za razvoj in preskušanje. Za preizkus kode RESTful vam ni treba zagnati večjega vsebnika. Enotno in integracijsko testiranje je lahko posledično veliko lažje.
Vzorec v seznamu 1 uporablja veliko privzetega vedenja za ustvarjanje privzetega Uporaba primer (bom razpravljal o Uporaba v naslednjem primeru) in poslušajte zahteve protokola HTTP na vratih 8182. The StreamServerHelper class začne poslušati na teh vratih in pošlje zahteve na Restlet ko pridejo.
Louvelov cilj podpiranja odjemalske RESTful Java je prav tako uresničen, kot lahko vidite v seznamu 2.
Seznam 2. Odjemalec Restlet
paket net.bosatsu.restlet.basic; import java.io.IOException; import org.restlet.Client; uvoz org.restlet.data.Protocol; javni razred SimpleClient {public static void main (String [] args) vrže IOException {String uri = (args.length> 0)? args [0]: "// localhost: 8182"; Odjemalec odjemalca = novi odjemalec (Protocol.HTTP); client.get (uri) .getEntity (). write (System.out); }} Z SimpleServer še vedno teče, zagon te nove odjemalske kode z enakimi odvisnostmi JAR naj natisne prijazen pozdrav na konzolo. Tiskanje izhoda v tem slogu očitno ne bi delovalo za binarno usmerjene vrste MIME, vendar je spet priročno izhodišče.
Primer, ki ni CRUD
Večina pedagoških primerov REST prikazuje CRUDish storitve (Create, Retrieve, Update, Delete) okoli preprostih predmetov. Čeprav ta slog zagotovo dobro deluje z REST, to še zdaleč ni edini pristop, ki je smiseln - in večina od nas je vseeno naveličana primerov CRUD. Naslednji primer prikazuje osnove aplikacije Restlet tako, da zavije odprtokodni črkovalnik Jazzy.
REST gre za upravljanje informacij in ne za sklicevanje na samovoljno vedenje, zato morate biti previdni, ko razmišljate o vedenjsko usmerjenem API-ju, kot je Jazzy. Trik je v tem, da API RESTful obravnavamo kot informacijski prostor za besede, ki obstajajo in ne obstajajo v uporabljenih slovarjih. Težavo bi lahko rešili na različne načine, vendar bo ta članek opredelil dva informacijska prostora. /slovar se uporablja za upravljanje besed v slovarju. / preverjanje črkovanja se uporablja za iskanje predlogov za besede, podobne napačno črkovanim besedam. Oba se osredotočata na informacije tako, da upoštevata odsotnost ali prisotnost besed v informacijskih prostorih.
V arhitekturi RESTful lahko ta ukaz HTTP vrne definicijo besede v slovar:
GET // localhost: 8182 / slovar /besedaVerjetno bi vrnil kodo odziva HTTP "Not Found" za besede, ki niso v slovarju. V tem informacijskem prostoru je lepo navesti, da besede ne obstajajo. Jazzy ne vsebuje definicij besed, zato bom vrnitev nekaterih vsebin pustil kot vajo za bralca.
Ta naslednji ukaz HTTP bi moral dodati besedo v slovar:
PUT // localhost: 8182 / slovar /beseda
Ta primer uporablja PUT ker lahko ugotovite, kaj je URI v /slovar informacijski prostor naj bo vnaprej in izdaja več PUTs ne bi smeli vplivati. (PUT je idempotentna zahteva, na primer GET. Večkratno izdajanje istega ukaza ne bi smelo vplivati.) Če želite dodati definicije, jih lahko kot telesa posredujete PUT vodnik. Če želite sčasoma sprejeti več definicij, boste morda želeli OBJAVI te opredelitve v, ker PUT je operacija prepisa.
Ne spreglejte sinhronizacije
Da bi bili primeri osredotočeni, ta članek ne posveča posebne pozornosti vprašanjem sinhronizacije. Ne ravnajte s svojo proizvodno kodo tako nonšalantno! Poiščite vir, kot je Java sočasnost v praksi za več informacij.
The Restlet primeri, ki jih bom ustvaril, morajo biti vezani na ustrezne informacijske prostore, kot je prikazano na seznamu 3.
Seznam 3. Preprost črkovalnik RESTful
paket net.bosatsu.restlet.spell; uvoz com.swabunga.spell.event.SpellChecker; uvoz com.swabunga.spell.engine.GenericSpellDictionary; uvoz com.swabunga.spell.engine.SpellDictionary; import java.io.File; uvoz java.io.FileNotFoundException; import java.io.IOException; uvoz org.restlet.data.Protocol; uvoz org.restlet. *; javni razred SpellCheckingServer razširja Application {public static String dictionary = "Restlet / dict / english.0"; javni statični SpellDictionary spellingDict; javni statični SpellChecker spellChecker; javni statični Restlet spellCheckerRestlet; javni statični Restlet DictionaryRestlet; static {poskusite {spellingDict = new GenericSpellDictionary (nova datoteka (slovar)); spellChecker = nov SpellChecker (spellingDict); spellCheckerRestlet = nov SpellCheckerRestlet (spellChecker); dictionaryRestlet = nov DictionaryRestlet (spellChecker); } catch (izjema e) {e.printStackTrace (); }} public static void main (String [] args) vrže izjemo {Component komponenta = new Component (); component.getServers (). add (Protocol.HTTP, 8182); SpellCheckingServer spellingService = nov SpellCheckingServer (); component.getDefaultHost (). attach ("", spellingService); komponenta.start (); } javni Restlet createRoot () {Usmerjevalnik usmerjevalnika = nov usmerjevalnik (getContext ()); router.attach ("/ črkovalnik / {beseda}", spellCheckerRestlet); router.attach ("/ dictionary / {beseda}", dictionaryRestlet); povratni usmerjevalnik; }} Ko sestavi primerek slovarja in črkovalnik, je nastavitev Restlet v seznamu 3 nekoliko bolj zapletena kot v prejšnjem osnovnem primeru (vendar ne veliko!). The SpellCheckingServer je primerek Restleta Uporaba. An Uporaba je organizacijski razred, ki koordinira uvajanje funkcionalno povezanih Restlet primerov. Okolica Komponenta vpraša an Uporaba za svoj koren Restlet s klicem na createRoot () metoda. Koren Restlet vrnjeno označuje, kdo naj odgovori na zunanje zahteve. V tem primeru je razred imenovan Usmerjevalnik se uporablja za odpošiljanje v podrejene informacijske prostore. Poleg izvedbe te vezave konteksta nastavi vzorec URL-ja, ki omogoča, da je del URL-ja z besedo na voljo kot atribut na zahtevi. To bo vzvod v Restlets, ustvarjene v seznamih 4 in 5.
The DictionaryRestlet, prikazan v seznamu 4, je odgovoren za obdelavo zahtev za manipulacijo z /slovar informacijski prostor.
