### javaでWebAPIを作りたい

java初心者です。javaを使ったWebアプリケーション作成を勉強しており  
「スッキリわかるサーブレット＆JSP入門」という本を読んで、Tomcatを使い、簡単なWebアプリを作れるようにはなりました。

今度はWebAPIを作ろうと考えているのですが、ネットで調べるとJerseyというライブラリを使った  
サンプルが多くみられます。

疑問なのですが、自分の認識ではHTMLの代わりにJsonなどを返しているのがWebAPIというイメージでした。  
なので現状のTomcat+sarvletでWebAPIは作れると感じているのですが、jerseyを使う理由はなんなのでしょうか？

また、業務で社内でつかう簡単なWebアプリケーションを作るのですが、  
やはりなんらかのフレームワークを利用するべきでしょうか？  
（これまでのシステムでは使用されていないようです。）
CC BY-SA 4.0
2018-07-06T00:38:17.263
45344
2018-07-07T08:27:59.350
29195
question
java
javaでのWebAPIの作成について
TomcatとServletだけでもWebAPIは作れます。しかし、Jerseyを使った方が簡単で標準的なものがつくれるいうことです。

Jerseyは、RESTfulなWebサービスを実現することに特化した、JavaのOSSの **フレームワーク**
です。一般的にフレームワークを使う理由として、以下のようなことが挙げられます。

・開発工数の削減  
・生産性や保守性の向上  
・設計レベルの欠陥を防ぐ  
・成果物の均質化

共通のロジックをフレームワークが実装済みのため、これらが実現できます。[このページ](http://openstandia.jp/oss_info/jersey/)にJerseyを使用してつくった、RESTfulなWebサービスクラスのサンプルがあります。これをJerseyを使用せずにつくったとしたら、こんなに短い行数では実現できないことはお分かりいただけると思います。また、JerseyはJava
EEの標準仕様の一つであるJAX-
RSを実装しているため、Jerseyを使用して開発されたWebAPIも独自仕様ものではなく、より標準的な仕様のものになると思います。

ただし、フレームワークは開発の規模が大きくなるほど効力を発揮するので、「業務で社内でつかう簡単なWebアプリケーション」であれば、Jerseyを使わないのも選択肢としてはアリかと思います。

[FYI]  
ちなみにTomcat
8.0では、以下のチェック処理が追加されているため、JSPに対するDELETEメソッドなどはエラーになります。サーブレットではなく、JSPで作ろうと考えている場合は、ご注意を。

[http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/servlet/JspServlet.java?view=diff&r1=1497877&r2=1497878&pathrev=1497878](http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/servlet/JspServlet.java?view=diff&r1=1497877&r2=1497878&pathrev=1497878)

このチェックが追加されたのは、JSP 2.3仕様で追加された以下の仕様の#4が関係しています。

<https://jcp.org/aboutJava/communityprocess/maintenance/jsr245/245-MR3.html>
CC BY-SA 4.0
2018-07-06T01:00:39.237
45346
2018-07-06T02:41:11.667
2018-07-06T02:41:11.667
21092
21092
45344
answer
正確かつオフィシャルな回答は[Jerseyサイトのトップページ"About"](https://jersey.github.io/)にあるかと思います。

ここでは別の観点から、かつもう少し具体的に説明を試みてみます。

* * *

Jerseyはフレームワークである、と自称しているわけですが、フレームワークというよりはServletをより便利にする機能拡張である、と捉えるのが理解しやすいかと思います。  
Jerseyを利用してWeb API開発を行ったとしても、Tomcat+ServletでWeb APIを作っていることには変わりありません。

例えば次のようなユーザ情報を `/user/[id]` のようなパスでIDによる検索機能を提供することを考えた場合、

```

    public class User {
    
        private long id;
        private String name;
    
        // getter, setter, ...
    }
    
```

素のServletで実装すると次のような感じになるかと思います。

```

    @WebServlet("/servlet/user/*")
    public class UserServlet extends HttpServlet {
    
        @Override
        protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
    
            long id = Long.parseLong(req.getPathInfo().split("/")[1]);
    
            User user = // idを用いたユーザ検索機能
    
            resp.setCharacterEncoding("UTF-8");
            resp.setContentType("application/json");
            resp.getWriter().append(toJsonStr(user)).close();
        }
    
        private String toJsonStr(User user) {
            return new StringBuilder()
                    .append("{")
                    .append("\"id\":").append(user.getId())
                    .append(",")
                    .append("\"name\":\"")
                    .append(user.getName()).append("\"")
                    .append("}").toString();
        }
    }
    
```

Jerseyという機能拡張を組み込めば、次のような形になります。

```

    @Path("/user/{id}")
    public class UserResource {
    
        @GET
        @Produces(MediaType.APPLICATION_JSON)
        public User user(@PathParam("id") long id) {
    
            User user = // idを用いたユーザ検索機能
    
            return user;
        }
    }
    
```

これは一例ですが、

> ネットで調べるとJerseyというライブラリを使ったサンプルが多くみられ

る理由は、前者のように素のServletを使って実現することもできるが、それよりJerseyを利用して後者のように書けたほうが嬉しい/楽だ、と多くのサンプル製作者が考えたからだ、ということになります。

> なんらかのフレームワークを利用するべきでしょうか？

一般的な話をすると、あるフレームワークを利用すべきかどうかは、そのフレームワークが提供する機能の(自分にとっての)有用性といったプラス面と、学習コストや費用等のマイナス面との兼ね合いで判断、ということになると思います。  
Jerseyに限って話をすると、OSSであり比較的学習コストも低いのでプラス面が上回る、とサンプル製作者らは考えているから紹介しているのだと思います。

* * *

補足:  
Jerseyは[狭義の意味](https://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF)において
**フレームワークではありません** (Jerseyが制御の反転を提供するわけではない)。  
今の段階であまりフレームワークという言葉にこだわるのは、むしろ理解の妨げになるかもしれません。
CC BY-SA 4.0
2018-07-07T08:27:59.350
45385
2018-07-07T08:27:59.350
2808
45344
answer