SpringDataRESTでのHTTPエンドポイントのカスタマイズ
1. 序章
Spring Data RESTは、RESTサービスに自然な多くの定型文を削除できます。
このチュートリアルでは、RESTのHTTPバインディングのデフォルトの一部をカスタマイズする方法について説明します。
2. SpringDataRESTリポジトリの基礎
開始するには、 CrudRepositoryインターフェイスを拡張する空のインターフェイスを作成し、エンティティのタイプとその主キーのタイプを指定します。
public interface UserRepository extends CrudRepository<WebsiteUser, Long> {}
デフォルトでは、 Springは必要なすべてのマッピングを生成し、適切なHTTPメソッドを介してアクセスできるように各リソースを構成し、適切なステータスコードを返します。
CrudRepository で定義されているすべてのリソースが必要ない場合は、基本的な Repository インターフェースを拡張し、必要なリソースのみを定義できます:
public interface UserRepository extends Repository<WebsiteUser, Long> {
void deleteById(Long aLong);
}
リクエストを受信すると、 Springは使用されているHTTPメソッドを読み取り、リソースタイプに応じて、インターフェースで定義されている適切なメソッドを呼び出すか、HTTPステータス 405(メソッドは許可されていません)を返します。 )それ以外の場合。
上記のコードを参照すると、SpringはDELETEリクエストを受信すると、deleteByIdメソッドを実行します。
3. 公開されるHTTPメソッドの制限
ユーザー管理システムがあると想像してみましょう。 したがって、UserRepository。があるかもしれません。
また、Spring Data RESTを使用しているため、CrudRepositoryを拡張することで多くのことが得られます。
@RepositoryRestResource(collectionResourceRel = "users", path = "users")
public interface UserRepository extends CrudRepository<WebsiteUser, Long> {}
すべてのリソースはデフォルトのCRUDパターンを使用して公開されるため、次のコマンドを発行します。
curl -v -X DELETE http://localhost:8080/users/<existing_user_id>
削除を確認するためにHTTPステータス204(コンテンツが返されません)を返します。
ここで、削除メソッドをサードパーティから隠し、内部で使用できるようにしたいとします。
次に、最初に deleteById メソッドシグネチャをインターフェイスに追加できます。これにより、構成することをSpringDataRESTに通知します。
次に、アノテーション @RestResource(exported = false)を使用できます。これにより、は、HTTPメソッドの公開をトリガーするときにこのメソッドをスキップするようにSpringを構成します。
@Override
@RestResource(exported = false)
void deleteById(Long aLong);
ここで、上記と同じ cUrl コマンドを繰り返すと、代わりにHTTPステータス 405(メソッドは許可されていません)を受け取ります。
4. サポートされているHTTPメソッドのカスタマイズ
@RestResource アノテーションを使用すると、リポジトリメソッドにマップされたURLパスとHATEOASリソース検出によって返されるJSONのリンクIDをカスタマイズすることもできます。 。
これを行うには、注釈のオプションのパラメーターを使用します。
- URLパスのパス
- リンクIDのrel
UserRepository に戻り、簡単なfindByEmailメソッドを追加しましょう。
WebsiteUser findByEmail(@Param("email") String email);
cUrlからhttp:// localhost:8080 / users / search / を実行すると、新しいメソッドが他のリソースとともに一覧表示されます。
{
"_links": {
"findByEmail": {
"href": "http://localhost:8080/users/search/findByEmail{?email}"
},
"self": {
"href": "http://localhost:8080/users/search/"
}
}
}
デフォルトのパスが気に入らない場合は、リポジトリメソッドを変更する代わりに、@RestResourceアノテーションを追加するだけです:
@RestResource(path = "byEmail", rel = "customFindMethod")
WebsiteUser findByEmail(@Param("email") String email);
また、リソースディスカバリーを再度実行すると、結果のJSONによって変更が確認されます。
{
"_links": {
"customFindMethod": {
"href": "http://localhost:8080/users/search/byEmail{?email}",
"templated": true
},
"self": {
"href": "http://localhost:8080/users/search/"
}
}
}
5. プログラムによる構成
HTTPメソッドへのアクセスを公開または制限するために、よりきめ細かいレベルの構成が必要になる場合があります。 たとえば、コレクションリソースのPOST、およびアイテムリソースのPUTとPATCHは、すべて同じsaveメソッドを使用します。
Spring Data REST 3.1以降、Spring Boot 2.1 で利用可能で、 ExposureConfigurationクラスを介して特定のHTTPメソッドの公開を変更できます。 この特定の構成クラスは、ラムダベースのAPIを公開して、グローバルルールとタイプベースのルールの両方を定義します。
たとえば、 ExposureConfiguration を使用して、UserRepositoryに対するPATCH要求を制限できます。
public class RestConfig implements RepositoryRestConfigurer {
@Override
public void configureRepositoryRestConfiguration(RepositoryRestConfiguration restConfig,
CorsRegistry cors) {
ExposureConfiguration config = restConfig.getExposureConfiguration();
config.forDomainType(WebsiteUser.class).withItemExposure((metadata, httpMethods) ->
httpMethods.disable(HttpMethod.PATCH));
}
}
6. 結論
この記事では、リソースでデフォルトでサポートされているHTTPメソッドをカスタマイズするようにSpringDataRESTを構成する方法について説明しました。
いつものように、この記事で使用されている例は、GitHubプロジェクトにあります。