إصدارات API في Spring Framework 7
استبدل المتحكمات المضاعفة بادئات الإصدارات بدعم إصدارات API الأصلي في Spring Framework 7.
// Version 1 controller
@RestController
@RequestMapping("/api/v1/products")
public class ProductControllerV1 {
@GetMapping("/{id}")
public ProductDtoV1 getProduct(
@PathVariable Long id) {
return service.getV1(id);
}
}
// Version 2 — duplicated structure
@RestController
@RequestMapping("/api/v2/products")
public class ProductControllerV2 {
@GetMapping("/{id}")
public ProductDtoV2 getProduct(
@PathVariable Long id) {
return service.getV2(id);
}
}
// Configure versioning once
@Configuration
public class WebConfig implements WebMvcConfigurer {
@Override
public void configureApiVersioning(
ApiVersionConfigurer config) {
config.useRequestHeader("X-API-Version");
}
}
// Single controller, version per method
@RestController
@RequestMapping("/api/products")
public class ProductController {
@GetMapping(value = "/{id}", version = "1")
public ProductDtoV1 getV1(@PathVariable Long id) {
return service.getV1(id);
}
@GetMapping(value = "/{id}", version = "2")
public ProductDtoV2 getV2(@PathVariable Long id) {
return service.getV2(id);
}
}
لا تكرار للمتحكمات
جميع الإصدارات في فئة متحكم واحدة؛ فقط الدوال المعالِجة الفردية تحمل سمة إصدار.
استراتيجية إصدار مركزية
بدّل من رأس HTTP إلى إصدار URL أو معامل استعلام في استدعاء configureApiVersioning واحد.
تطوّر تدريجي
أضف إصداراً جديداً لدالة واحدة دون المساس بنقاط نهاية غير مرتبطة أو إنشاء ملفات متحكم جديدة.
متاح منذ Spring Framework 7.0 (يتطلب Java 17+)
قبل Spring Framework 7، كانت إصدارات API تتطلب فئات متحكم منفصلة لكل إصدار (مثل /api/v1/products و /api/v2/products) مما يُكرّر تعيينات الطلبات ويُفرّق منطق الإصدارات عبر ملفات كثيرة. يقدّم Spring Framework 7 إصدارات أصلية عبر سمة version جديدة على @RequestMapping والتعليقات التوضيحية ذات الصلة بالإضافة إلى خطّاف configureApiVersioning في WebMvcConfigurer.