1概要

RESTパラダイムは、ここ数年でかなり前からあり続けていますが、それでもまだ注目を集めています。

RESTful APIは、さまざまな方法でJavaに実装できます。Spring、JAX-RSを使用することもできれば、賢くて勇気がある場合は単に独自のベアサーブレットを作成することもできます。必要なのは、HTTPメソッドを公開する機能だけです。残りは、それらをどのように編成するか、およびAPIを呼び出すときにクライアントをどのように誘導するかに関することだけです。

タイトルからわかるように、この記事ではJAX-RSについて説明します。しかし、「単なるAPI」とはどういう意味ですか?つまり、ここでの焦点は、JAX-RSとその実装との間の混乱を明確にし、適切なJAX-RS Webアプリケーションがどのように見えるかの例を提供することです。


2 Java EE

への組み込み

JAX-RSは、Java EEが提供する仕様、一連のインタフェース、および注釈にすぎません。そして、もちろん、実装もあります。よりよく知られているもののいくつかはhttp://resteasy.jboss.org[RESTEasy]とhttps://jersey.java.net/[Jersey]です。

また、JEE準拠のアプリケーションサーバーを構築することを決定した場合は、Oracleの担当者から、デプロイされたアプリケーションで使用するJAX-RS実装を他の多くの要素の間で提供する必要があることがわかります。それがJava Enterprise Edition

Platform

と呼ばれる理由です。

仕様と実装の別の良い例はhttps://docs.oracle.com/javaee/6/tutorial/doc/bnbpz.html[JPA]とhttp://hibernate.org/[Hibernateです。


2.1. 軽量ウォーズ

それでは、これらすべてが開発者にとってどのように役立つのでしょうか。その助けとなるのは、私たちのデプロイ可能物は非常に細いことができ、またそうすべきであり、アプリケーションサーバーに必要なライブラリを提供させることです。これは、RESTful APIの開発時にも適用されます。最終成果物には、使用されているJAX-RS実装に関する情報を含めないでください。

確かに、私たちは実装を提供することができます(

ここ

はRESTeasyのためのチュートリアルです)。しかし、それでは、アプリケーションを「Java EEアプリケーション」と呼ぶことはできなくなります。明日誰かが来て「GlassfishやPayaraに切り替える時間があれば、JBossが高すぎます!

独自の実装を提供する場合は、サーバーが自身の実装を除外することを確実に認識するようにする必要があります。これは通常、デプロイ可能な内部に独自のXMLファイルを配置することによって行われます。言うまでもなく、そのようなファイルには、3年前に会社を辞めた開発者を除いて、だれも知らないあらゆる種類のタグや指示が含まれている必要があります。


2.2. 常にあなたのサーバーを知っている

私たちはこれまで、私たちが提供してきたプラットフォームを利用するべきだと述べました。

使用するサーバーを決定する前に、少なくともプロダクション環境に対して、どのようなJAX-RS実装(名前、ベンダー、バージョン、および既知のバグ)が提供されるのかを確認する必要があります。たとえば、GlassfishはJerseyに付属していますが、WildflyまたはJbossはRESTEasyに付属しています。

もちろん、これは研究に少し時間がかかることを意味しますが、プロジェクトの開始時または別のサーバーへの移行時に一度だけ行われることになっています。


3例

JAX-RSを使い始める場合、最短のパスは次のとおりです。

pom.xml

に次の依存関係を持つMaven Webアプリケーションプロジェクトを作成します。

<dependency>
    <groupId>javax</groupId>
    <artifactId>javaee-api</artifactId>
    <version>7.0</version>
    <scope>provided</scope>
</dependency>

すでに多くのアプリケーションサーバーが実装されているので、私たちはJavaEE 7を使用しています。そのAPI jarには、パッケージ

javax.ws.rs

にある、使用する必要がある注釈が含まれています。スコープが「提供」されているのはなぜですか?このjarファイルは最終ビルドに含める必要もないため、コンパイル時に必要になります。実行時にサーバーから提供されます。

依存関係が追加された後、まずエントリークラスを書く必要があります。


javax.ws.rs.core.Application

を拡張し、__javax.ws.rs.ApplicationPathのアノテーションが付けられた空のクラス

@ApplicationPath("/api")
public class RestApplication extends Application {
}

エントリパスを

/apiと定義しました。リソースに対して他のパスを宣言する場合は、

/api__のプレフィックスが付けられます。

次に、リソースを見てみましょう。

@Path("/notifications")
public class NotificationsResource {
    @GET
    @Path("/ping")
    public Response ping() {
        return Response.ok().entity("Service online").build();
    }

    @GET
    @Path("/get/{id}")
    @Produces(MediaType.APPLICATION__JSON)
    public Response getNotification(@PathParam("id") int id) {
        return Response.ok()
          .entity(new Notification(id, "john", "test notification"))
          .build();
    }

    @POST
    @Path("/post/")
    @Consumes(MediaType.APPLICATION__JSON)
    @Produces(MediaType.APPLICATION__JSON)
    public Response postNotification(Notification notification) {
        return Response.status(201).entity(notification).build();
    }
}

我々は我々のアプリが実行されているかどうかを呼び出すための単純なpingエンドポイント、通知のためのGETとPOSTを持っています(これは属性とゲッターとセッターを含むPOJOです)。

JEE7を実装している任意のアプリケーションサーバーにこの戦争を展開すると、次のコマンドが機能します。

curl http://localhost:8080/simple-jaxrs-ex/api/notifications/ping/
curl http://localhost:8080/simple-jaxrs-ex/api/notifications/get/1

curl -X POST -d '{"id":23,"text":"lorem ipsum","username":"johana"}'
  http://localhost:8080/simple-jaxrs-ex/api/notifications/post/
  --header "Content-Type:application/json"

simple-jaxrs-exはWebアプリケーションのコンテキストルートです。

これはGlassfish 4.1.0とWildfly 9.0.1.Finalでテストされました。最後の2つのコマンドはGlassfish 4.1.1では動作しないことに注意してください。 。 JSONのシリアル化に関して、このGlassfishバージョンの既知の問題と思われます(このサーバーバージョンを使用する必要がある場合は、JSONマーシャリングを自分で管理する必要があります)


4結論

この記事の最後で、JAX-RSは強力なAPIであり、必要なもののほとんど(すべてではないにしても)がWebサーバーによって既に実装されていることを忘れないでください。デプロイ可能なものを管理不能な数のライブラリに変える必要はありません。

この記事は簡単な例を示しており、事情はもっと複雑になるかもしれません。例えば、あなたはあなた自身のマーシャラを書きたくなるかもしれません。

それが必要なときは、JerseyやResteasyなどの具体的な実装ではなく、JAX-RSで問題を解決するチュートリアルを探してください。あなたの問題は1つか2つのアノテーションで解決できる可能性が非常に高いです。