streamalism.org

1. Áttekintés

A REST paradigma már jó néhány éve létezik, és még mindig nagy figyelmet kap.

A RESTful API többféleképpen is megvalósítható a Java-ban: használhatja a Spring-et, a JAX-RS-t, vagy csak saját puszta szervleteket írhat, ha elég jó és bátor vagy. Csak a HTTP-módszerek feltárására van szükség - a többi csak arról szól, hogyan szervezi azokat, és hogyan irányítja az ügyfelet, amikor az API-jához hív.

Amint a címből kitalálhatja, ez a cikk a JAX-RS-t fogja ismertetni. De mit jelent a „csak egy API”? Ez azt jelenti, hogy itt a hangsúly a JAX-RS és megvalósításai közötti összetévesztés tisztázására és egy példa felkínálására szolgál, hogy hogyan néz ki egy megfelelő JAX-RS webapp.

2. Felvétel a Java EE-be

A JAX-RS nem más, mint a Java EE által kínált specifikáció, interfészek és kommentárok összessége. És akkor természetesen megvan a megvalósítás; néhány ismertebb a RESTEasy és a Jersey.

Továbbá, ha valaha úgy dönt, hogy JEE-kompatibilis alkalmazásszervert épít, akkor az Oracle srácai elmondják, hogy a kiszolgálónak egyebek mellett JAX-RS megvalósítást kell biztosítania a telepített alkalmazások számára. Ezért hívják Java Enterprise Edition-nek Felület.

A specifikáció és a megvalósítás másik jó példája a JPA és a Hibernate.

2.1. Könnyű háborúk

Tehát hogyan segít mindez nekünk, a fejlesztőknek? A segítség abban áll, hogy a telepíthetőségeink nagyon vékonyak lehetnek és kell, hogy legyenek, lehetővé téve az alkalmazásszerver számára a szükséges könyvtárak biztosítását. Ez érvényes a RESTful API fejlesztésekor is: a végleges műterméknek nem szabad tartalmaznia információkat a használt JAX-RS megvalósításról.

Természetesen biztosítani tudjuk a megvalósítást (itt van egy oktatóanyag a RESTeasy számára). De akkor már nem nevezhetjük alkalmazásunkat „Java EE alkalmazásnak”. Ha holnap jön valaki és azt mondja:Oké, ideje áttérni a Glassfish-re vagy a Payarára, a JBoss túl drága lett!„Lehet, hogy képesek vagyunk rá, de ez nem lesz könnyű feladat.

Ha saját megvalósítást biztosítunk, akkor meg kell győződnünk arról, hogy a szerver tudja-e kizárni a sajátját - ez általában úgy történik, hogy egy saját XML-fájl van a telepíthetőben. Mondanom sem kell, hogy egy ilyen fájlnak tartalmaznia kell mindenféle címkét és utasítást, amelyekről senki sem tud semmit, kivéve azokat a fejlesztőket, akik három évvel ezelőtt hagyták el a céget.

2.2. Mindig ismerje a szervert

Eddig azt mondtuk, hogy ki kell használnunk a felajánlott platform előnyeit.

Mielőtt eldöntenénk, hogy melyik kiszolgálót kell használni, meg kell néznünk, hogy a JAX-RS megvalósítását (név, gyártó, verzió és ismert hibák) legalább a gyártási környezetek számára mit nyújtja. Például az Glassfish Jersey-vel, míg a Wildfly vagy Jboss a RESTEasy-val érkezik.

Ez természetesen egy kis időt jelent a kutatásra, de állítólag csak egyszer, a projekt elején vagy egy másik szerverre történő áttelepítéskor végezhető el.

3. Példa

Ha el akarja kezdeni a JAX-RS játékot, akkor a legrövidebb út: legyen egy Maven webapp projekt, amelynek a következő függősége van a pom.xml:

 javax javaee-api 7.0 biztosított 

JavaEE 7-et használunk, mivel már rengeteg alkalmazáskiszolgáló implementálja. Ez az API jar a csomagban található feljegyzéseket tartalmazza, amelyeket használnia kell javax.ws.rs. Miért „biztosított” a hatókör? Mivel ennek az üvegnek sem kell a végső összeállításban lennie - fordításkor szükségünk van rá, és a szerver biztosítja a futási időre.

A függőség hozzáadása után először meg kell írnunk a belépési osztályt: egy üres osztályt, amely kiterjed javax.ws.rs.core.Application és azzal van jelölve javax.ws.rs.ApplicationPath:

A @ApplicationPath ("/ api") nyilvános osztály A RestApplication kiterjeszti az alkalmazást {} 

Meghatároztuk a belépési útvonalat / api. Bármilyen más utat is deklarálunk az erőforrásainkhoz, azokat előtaggal látjuk el / api.

Ezután nézzük meg az erőforrást:

@Path ("/ értesítések") public class NotificationsResource {@GET @Path ("/ ping") public Response ping () {return Response.ok (). Entitás ("Online szolgáltatás"). Build (); } @GET @Path ("/ get / {id}") @Produces (MediaType.APPLICATION_JSON) nyilvános válasz getNotification (@PathParam ("id") int id) {return Response.ok () .entity (new Notification (id) , "john", "teszt értesítés")) .build (); } @POST @Path ("/ post /") @Cumsumes (MediaType.APPLICATION_JSON) @Produces (MediaType.APPLICATION_JSON) public Response postNotification (Notification értesítés) {return Response.status (201) .entity (értesítés) .build () ; }}

Van egy egyszerű ping végpontunk, amellyel felhívhatjuk és ellenőrizhetjük, hogy fut-e az alkalmazásunk, van-e GET és POST egy értesítéshez (ez csak egy POJO attribútumokkal, plusz getterekkel és beállítókkal).

Telepítse ezt a háborút minden olyan alkalmazáskiszolgálóra, amely JEE7-et valósít meg, és a következő parancsok működnek:

curl // localhost: 8080 / simple-jaxrs-ex / api / értesítések / ping / curl // localhost: 8080 / simple-jaxrs-ex / api / értesítések / get / 1 curl -X POST -d '{"id" : 23, "text": "lorem ipsum", "felhasználónév": "johana"} '// localhost: 8080 / simple-jaxrs-ex / api / értesítések / post / --header "Tartalom-típus: alkalmazás / json "

Ahol az simple-jaxrs-ex a webapp kontextusgyökere.

Ezt a Glassfish 4.1.0 és a Wildfly 9.0.1.Final programmal tesztelték. Kérjük, vegye figyelembe, hogy az utolsó két parancs nem fog működni a Glassfish 4.1.1 verzióval, ez a hiba miatt. Nyilvánvalóan ismert kérdés ebben a Glassfish verzióban, a JSON sorosítását illetően (ha ezt a szerver verziót kell használnia, akkor egyedül kell kezelnie a JSON marsallt).

4. Következtetés

A cikk végén ne feledje, hogy a JAX-RS egy erőteljes API, és a szükséges dolgok nagy részét (ha nem is az összes) a webszerver már megvalósítja. Nem kell a telepíthetőt kezelhetetlen könyvtárakká alakítani.

Ez az írás egy egyszerű példát mutat be, és a dolgok bonyolultabbá válhatnak. Például érdemes megírnia saját marsallereit. Ha erre szükség van, keressen olyan oktatóanyagokat, amelyek megoldják a problémát a JAX-RS szolgáltatással, nem pedig a Jersey, Resteasy vagy más konkrét megvalósítással. Nagyon valószínű, hogy problémája megoldható egy vagy két kommentár segítségével.