Open-source Restlet API znižuje pracovné zaťaženie spojené s vytváraním a konzumáciou RESTful API v Jave. V tomto druhom článku v REST pre vývojárov Java série, Brian Sletten vám predstavuje Restlet a prechádza ukážkovou aplikáciou pri nasadení jeho rozhraní do kontajnerov servletov, ktoré dnes používate, a zároveň sa pripravuje na systémy budúcnosti. Brian tiež stručne predstavuje JSR 311: JAX-RS, snahu spoločnosti Sun o integráciu rozhraní RESTful API s balíkom Java EE.
Vývojári v prostredí Java sa už dávno zaujímajú o architektonický štýl REST, ale len málo z nich ešte prekonalo vzdialenosť medzi známym svetom objektov a svetom RESTful zdrojov. Aj keď by sa nám mohlo páčiť, že služby RESTful môžu byť produkované alebo spotrebované v iných jazykoch, nenávidíme potrebu prevádzania údajov do a z bajtových tokov. Neznášame, keď musíme myslieť na HTTP, keď používame nástroje ako Apache HTTP Client. Túžobne sa pozeráme na objekty vytvorené wsdl2java príkaz, ktorý nám umožňuje odovzdávať argumenty do služby SOAP rovnako ľahko ako každé iné volanie metódy, pričom podrobnosti vyvolania vzdialenej služby zametieme pod koberec. A zistíme, že model servletu je len trochu príliš odpojený od produkovaných zdrojov. Stačí povedať, že keď sme už boli schopný vybudovať RESTful služby úplne od začiatku, nebol to príjemný zážitok.
REST pre vývojárov Java
Prečítajte si sériu:
- 1. časť: Je to o informáciách
- Časť 2: Restlet pre unavených
- Časť 3: NetKernel
Politické problémy niekedy spojili technické prekážky. Mnoho manažérov sa domnieva, že webové služby založené na SOAP sú predpísaným spôsobom budovania architektúr orientovaných na služby (SOA) v prostredí Java EE. To sa mení so vznikom dôležitých aktivít, ako sú JSR 311, JAX-RS: Java API pre RESTful Web Services, o ktorých sa dozviete v tomto článku. Ak nič iné, toto úsilie legitimizuje RESTful vývoj v priestore JEE.
Medzitým prišla pomoc. Elegantným spôsobom rámec otvoreného zdroja Restlet uľahčuje predchádzanie tŕnistým problémom, ktoré môžu vyplynúť z použitia tradičnej technológie JEE na vytváranie a využívanie služieb RESTful.
Restletove korene
V snahe vyriešiť niektoré technické problémy spojené s činnosťou REST v prostredí Java sa Jérome Louvel, francúzsky softvérový konzultant, snažil vytvoriť rámec, ktorý by poskytoval prirodzenejšie riešenie. Najprv sa pozeral na prostredie NetKernel ako na východiskový bod. Aj keď sa mu to páčilo, nebolo to ideálne riešenie pre rámec zameraný na API, ktorý sa snažil sprístupniť. Táto skúsenosť však pomohla ovplyvniť jeho uvažovanie o druhoch vecí, ktoré môže prostredie orientované na REST ponúknuť. (Nasledujúci článok v tejto sérii bude bližšie skúmať NetKernel.)
Keď Louvel pracoval na svojom rámci, vytvoril tri ciele:
- Pre základné použitie by mali byť jednoduché akcie jednoduché. Predvolené hodnoty by mali pracovať s minimálnym úsilím, ale mali by umožňovať aj zložitejšie konfigurácie.
- Kód napísaný do tohto API by mal byť prenosný naprieč kontajnermi. Aj keď systémy založené na servletoch možno presúvať medzi kontajnermi, ako sú Tomcat, Jetty a IBM WebSphere, Louvel mal na mysli väčší obraz. Špecifikácia servletu je viazaná na HTTP a blokujúci I / O model. Chcel, aby jeho API bolo od oboch oddeliteľné a nasaditeľné do dnes používaných kontajnerov. Tiež chcel, aby boli použiteľné s malým úsilím v alternatívnych a vznikajúcich kontajneroch, ako sú Grizzly, AsyncWeb a Simple Framework.
- Malo by to obohatiť nielen stranu servera, ktorá produkuje rozhrania RESTful v Jave, ale aj stranu klienta. The
HttpURLConnectiontriedy a klient Apache HTTP sú príliš nízke úrovne na to, aby sa mohli čisto integrovať priamo do väčšiny aplikácií.
Majúc na pamäti tieto ciele, vydal sa na výrobu Restlet API. Po niekoľkých rokoch vývoja sa API stalo stabilným a okolo neho vyrástla komunita. Dnes má jadro API živú užívateľskú základňu a prebiehajú významné aktivity na podporu integrácie s inými súbormi nástrojov a iniciatívami, ako je JAX-RS. (Louvel je teraz v skupine odborníkov JAX-RS.)
Základy restletu
Základný server s rozhraním Restlet API už nemusí byť jednoduchší, ako je uvedené v zozname 1.
Zoznam 1. Základný server s restletom
balík net.bosatsu.restlet.basic; import org.restlet.Restlet; import org.restlet.Server; import org.restlet.data.MediaType; import org.restlet.data.Protocol; import org.restlet.data.Request; import org.restlet.data.Response; public class SimpleServer {public static void main (String [] args) throws Exception {Restlet restlet = new Restlet () {@Override public void handle (Request request, Response response) {response.setEntity ("Hello, Java RESTafarians!", MediaType.TEXT_PLAIN); }}; // Vyvarujte sa konfliktom s ostatnými kontajnermi Java, ktoré počúvajú na 8080! nový server (Protocol.HTTP, 8182, restlet) .start (); }}Táto aplikácia nerobí veľa (okrem šírenia dobrej nálady), ale ukazuje dva základné princípy spoločnosti Restlet. Po prvé, jednoduché veci sú jednoduché. Zložitejšie činnosti sú určite možné, ale obávate sa ich iba vtedy, keď potrebujete. RESTu nechýba schopnosť presadiť zabezpečenie, obmedzenia, vyjednávanie obsahu alebo iné dôležité úlohy. Tie zostávajú do značnej miery ortogonálne činnosti, úplne odlišné od procesu uspokojovania RESTful API. Podľa potreby zložitosť navrstvíte.
Po druhé, kód v zozname 1 je navrhnutý tak, aby bol prenosný medzi typmi kontajnerov. Všimnite si, že neurčuje kontajner. Restlets sú skutočné zdroje, ktoré nakoniec odpovedajú na požiadavky. Nerozlišuje sa medzi kontajnerom vybavujúcim požiadavku a odpovedačom informačných zdrojov, ako to môže byť v modeli servletu. Ak napíšete kód do IDE a pridáte závislosti na org.restlet.jar a com.noelios.restlet.jar archívy, môžete aplikáciu spustiť a mala by sa vám zobraziť správa protokolu, ako je táto:
7. decembra 2008 23:37:32 com.noelios.restlet.http.StreamServerHelper štart INFO: Spustenie interného servera HTTP Nasmerujte prehliadač na // localhost: 8182, a mali by ste vidieť priateľský pozdrav.
V zákulisí org.restlet.jar obsahuje všetky hlavné rozhrania pre toto API. The com.noelios.restlet.jar obsahuje základnú implementáciu týchto rozhraní a poskytuje predvolenú schopnosť spracovania HTTP. S týmto motorom HTTP nebudete chcieť ísť do výroby, ale je to mimoriadne vhodné pre vývojové a testovacie účely. Na otestovanie kódu RESTful nemusíte spustiť hlavný kontajner. Výsledkom môže byť testovanie jednotiek a integrácie.
Vzorka v zozname 1 používa na vytvorenie predvoleného nastavenia veľa predvoleného správania Aplikácia inštancia (budem diskutovať Aplikácia v nasledujúcom príklade) a počúvajte požiadavky protokolu HTTP na porte 8182. The StreamServerHelper trieda začne počúvať na tomto porte a odošle požiadavky do Restlet napríklad ako prichádzajú.
Cieľ spoločnosti Louvel, ktorým je podpora RESTful Java na strane klienta, sa dá ľahko splniť, ako vidíte v zozname 2.
Zoznam 2. Klient Restlet
balík net.bosatsu.restlet.basic; import java.io.IOException; import org.restlet.Client; import org.restlet.data.Protocol; public class SimpleClient {public static void main (String [] args) hodí IOException {String uri = (args.length> 0)? args [0]: "// localhost: 8182"; Klient klient = nový klient (Protocol.HTTP); client.get (uri) .getEntity (). write (System.out); }} Vďaka SimpleServer stále spustený, spustenie tohto nového kódu klienta s rovnakými závislosťami JAR by malo vytlačiť priateľský pozdrav do konzoly. Tlač výstupu týmto štýlom by samozrejme nefungovala pre binárne orientované typy MIME, ale opäť je to vhodný východiskový bod.
Príklad, ktorý nie je CRUD
Väčšina pedagogických príkladov REST zobrazuje služby CRUDish (vytváranie, načítanie, aktualizácia, mazanie) okolo jednoduchých objektov. Aj keď tento štýl s REST určite funguje dobre, nie je to zďaleka jediný prístup, ktorý dáva zmysel - a väčšinu z nás už unavujú príklady CRUD. Nasledujúci príklad demonštruje základy aplikácie Restlet zabalením kontroly pravopisu Jazzy open source.
REST je o správe informácií, nie o vyvolávaní svojvoľného správania, takže pri zvažovaní API zameraného na správanie, ako je Jazzy, musíte byť opatrní. Trik spočíva v zaobchádzaní s rozhraním RESTful API ako s informačným priestorom pre slová, ktoré existujú a neexistujú v používaných slovníkoch. Problém je možné vyriešiť rôznymi spôsobmi, ale v tomto článku budú definované dva informačné priestory. / slovník sa používa na správu slov v slovníku. / kontrola pravopisu sa používa na vyhľadanie návrhov slov podobných nesprávne napísaným slovám. Obidve sa zameriavajú na informácie zvážením absencie alebo prítomnosti slov v informačných priestoroch.
V architektúre RESTful by tento príkaz HTTP mohol vrátiť definíciu slova v slovníku:
ZÍSKAŤ // localhost: 8182 / dictionary /slovoPravdepodobne by vrátil kód odpovede HTTP „Nenašiel sa“ pre slová, ktoré sa nenachádzajú v slovníku. V tomto informačnom priestore je dobré naznačiť, že slová neexistujú. Jazzy neposkytuje definície slov, takže vrátenie časti obsahu nechám ako cvičenie pre čitateľa.
Tento ďalší príkaz HTTP by mal do slovníka pridať slovo:
PUT // localhost: 8182 / dictionary /slovo
Tento príklad používa PUT pretože môžete zistiť, aký je URI v / slovník informačný priestor by mal byť vopred a vydávať viac PUTs by nemali robiť rozdiely. (PUT je idempotentná požiadavka, ako ZÍSKAJTE. Vydanie toho istého príkazu viackrát by nemalo mať vplyv.) Ak chcete pridať definície, môžete ich odovzdať ako orgány do PUT psovod. Ak chcete v priebehu času prijať viac definícií, možno budete chcieť POST tieto definície v, pretože PUT je operácia prepísania.
Neprehliadnite synchronizáciu
V záujme zachovania zamerania príkladov tento článok nevenuje osobitnú pozornosť problémom synchronizácie. S výrobným kódom nezaobchádzajte tak nonšalantne! Poraďte sa so zdrojom, ako je napr Java súbežnosť v praxi Pre viac informácií.
The Restlet inštancie, ktoré vytvorím, musia byť viazané na príslušné informačné priestory, ako je uvedené v zozname 3.
Zoznam 3. Jednoduchá RESTful kontrola pravopisu
balíček net.bosatsu.restlet.spell; import com.swabunga.spell.event.SpellChecker; import com.swabunga.spell.engine.GenericSpellDictionary; import com.swabunga.spell.engine.SpellDictionary; import java.io.File; import java.io.FileNotFoundException; import java.io.IOException; import org.restlet.data.Protocol; import org.restlet. *; verejná trieda SpellCheckingServer rozširuje aplikáciu {public static String dictionary = "Restlet / dict / english.0"; verejný statický SpellDictionary spellingDict; verejný statický SpellChecker spellChecker; public static Restlet spellCheckerRestlet; verejný statický Restlet dictionaryRestlet; static {try {spellingDict = new GenericSpellDictionary (nový súbor (slovník)); spellChecker = nový SpellChecker (spellingDict); spellCheckerRestlet = nový SpellCheckerRestlet (spellChecker); dictionaryRestlet = nový DictionaryRestlet (spellChecker); } catch (Výnimka e) {e.printStackTrace (); }} public static void main (String [] args) vyvolá Výnimku {Component component = new Component (); component.getServers (). add (Protocol.HTTP, 8182); SpellCheckingServer spellingService = nový SpellCheckingServer (); component.getDefaultHost (). attach ("", spellingService); component.start (); } public Restlet createRoot () {Router router = new Router (getContext ()); router.attach ("/ spellchecker / {word}", spellCheckerRestlet); router.attach ("/ dictionary / {word}", dictionaryRestlet); spätný smerovač; }} Po vytvorení inštancie slovníka a kontroly pravopisu je nastavenie Restletu v zozname 3 o niečo komplikovanejšie ako v predchádzajúcom základnom príklade (ale nie o veľa!). The SpellCheckingServer je inštancia Restletu Aplikácia. An Aplikácia je organizačná trieda, ktorá koordinuje nasadenie funkčne spojených Restlet inštancie. Okolie Komponent pýta sa Aplikácia pre svoj koreň Restlet zavolaním na createRoot () metóda. Koreň Restlet vrátené označuje, kto by mal odpovedať na externé požiadavky. V tomto príklade sa nazýva trieda Router sa používa na odoslanie do podriadených informačných priestorov. Okrem vykonania tejto kontextovej väzby nastavuje vzor adresy URL, ktorý umožňuje, aby bola „požiadavková“ časť adresy URL k dispozícii ako atribút na požiadanie. Toto sa využije v Restlets vytvorené v zoznamoch 4 a 5.
The DictionaryRestlet, uvedený v zozname 4, je zodpovedný za vybavovanie požiadaviek na manipuláciu s / slovník informačný priestor.
