Edit Question - KnowledgeHub

Title Body

Best practice for REST resource versioning is putting version information into Accept/Content-Type headers of HTTP request leaving URI intact. Here is the sample request/response to REST API for retrieving system information: ==> GET /api/system-info HTTP/1.1 Accept: application/vnd.COMPANY.systeminfo-v1+json <== HTTP/1.1 200 OK Content-Type: application/vnd.COMPANY.systeminfo-v1+json { “session-count”: 19 } Pay attention that version is specified in MIME type. Here is another request/response for version 2: ==> GET /api/system-info HTTP/1.1 Accept: application/vnd.COMPANY.systeminfo-v2+json <== HTTP/1.1 200 OK Content-Type: application/vnd.COMPANY.systeminfo-v2+json { “uptime”: 234564300, “session-count”: 19 } See http://barelyenough.org/blog/tag/rest-versioning/ for more explanation and examples. Is it possible to implement this approach easily in Java-targeted JAX-RS based implementations, such as Jersey or Apache CXF? The goal is to have several @Resource classes with the same @Path value, but serving the request based on actual version specified in MIME type? I've looked into JAX-RS in general and Jersey in particlaur and found no support for that. Jersey doesn't give a chance to register two resources with the same path. Replacement for WebApplicationImpl class needs to implemented to support that. Can you suggest something? NOTE: It is required for multiple versions of the same resource needs to be available simultaneously. New versions may introduce incompatibale changes.

Tags (comma-separated) Cancel