REST APIのバージョン管理の形式としてコンテンツタイプのネギシエーションを使用する予定ですが、本来よりも複雑に見えます。次のサンプルコードを考えると：
@RestController
@RequestMapping("/products")
ProductController {
.......
@RequestMapping(value = "/{productID}", method = RequestMethod.GET, produces = "productVersion2/json")
public ResponseEntity<ProductV2> getVersion2(@PathVariable String productID) {
.......
return new ResponseEntity<ProductV2>(product, HttpStatus.OK);
たとえばpostmanからこれをテストすると、正しいメソッドが呼び出されますが、応答としてHTTP 406 NotAcceptableが返されます。私はいくつかの場所を探していましたが、この作業を行うために何をする必要があるかについての適切な説明が記載されたページが見つかりませんでした。
応答は他のすべての要求と同じようにjsonで解析されますが、応答オブジェクトは変更されます。これを行うことで、同じAPIの複数の「バージョン」をサポートでき、同じURI /リソースにアクセスしながら、クライアントを新しいAPIに徐々に移行できると考えられます。
誰もがこれがスプリングブーツでどのように解決できるかについての良いチュートリアルまたはステップバイステップガイドを指摘できますか？
私はこの記事を読みました：http：//spring.io/blog/2013/05/11/content-negotiation-using-spring-mvc/#combined-controllerしかし、何が必要かを明確に理解することができませんでしたそれを機能させるために
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加