IF_REST_APPLICATION原理IF_REST_APPLICATION实现路径匹配的核心原理是你预先定义一套“路由规则”即 URI 模板与后端 ABAP 处理类的绑定关系当客户端请求到来时SAP REST 框架中的“路由器”CL_REST_ROUTER会找出匹配度最高的那条规则自动创建对应的处理类实例然后由其处理该请求。下面我们来完整地拆解一下这个过程中的关键环节。 启动从 ICF 到 REST 应用整个流程始于 SAP 互联网通信框架 (ICF)。当客户端发送 HTTP 请求例如http://server/sap/bc/rest_cars/Cars/47时ICF 的请求会被你预先注册的 REST 处理类通常继承自CL_REST_HTTP_HANDLER捕获。这个通用的处理类会接管后续流程调用你需要实现的IF_REST_APPLICATION~GET_ROOT_HANDLER方法来获取整个 REST 应用的根路由器对象。这一步标志着从 ICF 的 http 层正式切入了专门的 REST 处理框架。️ 定义注册 URI 模板与后端类接下来你需要在一个继承自CL_REST_HTTP_HANDLER的子类中实现IF_REST_APPLICATION~GET_ROOT_HANDLER方法在其中完成最核心的路径匹配规则定义METHOD if_rest_application~get_root_handler. DATA(lo_router) NEW cl_rest_router( ). 注册路径模板 /Cars 到后端类 CL_REST_SAMPLE_CARS lo_router-attach( iv_template /Cars iv_handler_class CL_REST_SAMPLE_CARS ). 注册带参数和正则表达式的模板 lo_router-attach( iv_template /Car/{ID:[1-9][0-9]*} iv_handler_class CL_REST_SAMPLE_CAR ). ro_root_handler lo_router. ENDMETHOD.上面这段代码的逻辑在于创建路由器首先创建一个CL_REST_ROUTER对象它是整个路径匹配的执行中枢。绑定通过反复调用ATTACH方法将URI 模板IV_TEMPLATE和后端 ABAP 处理类名IV_HANDLER_CLASS紧密绑定起来。 匹配路径如何找到后端类CL_REST_ROUTER的工作就是根据请求的 URI 找到正确的处理器。SAP REST 库支持三种由简单到复杂的 URI 模板类型静态模板 (Static Templates)这是最直接的匹配方式。只有当请求的路径与模板字符串完全一致时才会被匹配。代码示例lo_router-attach( iv_template /Cars ... )匹配路径仅匹配.../Cars带属性的模板 (With URI Attribute)使用{属性名}作为占位符匹配该位置上的任意内容。代码示例lo_router-attach( iv_template /Cars_history/{MANUFACTURER} ... )匹配路径可以匹配.../Cars_history/ferrari也可以匹配.../Cars_history/maserati。带正则表达式的模板 (With URI Regular Expression Attribute)这是功能最强的模式允许用ABAP 正则表达式来精确控制匹配范围和格式。代码示例lo_router-attach( iv_template /Car/{ID:[1-9][0-9]*} ... )匹配路径可以匹配.../Car/1也可以匹配.../Car/47但由于正则[1-9][0-9]*的限制.../Car/0将无法匹配。处理路径冲突为了避免冲突CL_REST_ROUTER会使用一个高效的排序算法来决定最终使用哪个处理类。该算法会优先选择**“文字字符”**不是用{}包裹的变量部分最多的模板。例如对于一个请求cars/1/color模板A/cars/{ID}/color模板B/cars/{ID}/{TYRE}匹配算法会计算每个模板的精确文字字符数模板A包含文字/cars/、/color共6个c a r s /和c o l o r。模板B包含文字/cars/共1个。计算得出模板A 胜出因为它能更精确地描述这个请求。这确保了最相关的后端类会被优先调用。 执行实例化与处理当CL_REST_ROUTER找到最佳匹配的模板后框架会动态创建一个该后端处理类iv_handler_class的新实例。请求分发路由器会调用这个处理类实例的HANDLE方法并将 REST 请求对象IO_REQUEST和响应对象IO_RESPONSE作为参数传入。资源处理最后后端处理类如CL_REST_RESOURCE的子类中的对应方法如GETPOST被执行生成响应内容。 交互流程总结整个流程可以概括为下图所示的交互流程后端处理类应用类(IF_REST_APPLICATION)路由器(CL_REST_ROUTER)ICF框架REST 客户端后端处理类应用类(IF_REST_APPLICATION)路由器(CL_REST_ROUTER)ICF框架REST 客户端路由器存储了URI模板 - 后端类的映射关系1. HTTP请求 (e.g., GET /sap/bc/rest_cars/Cars/47)2. 调用 GET_ROOT_HANDLER()在方法内部构建并返回 CL_REST_ROUTER实例3. 返回配置好的路由器实例 (ro_root_handler)4. 将请求路由信息发送给路由器执行匹配5. 解析请求路径与内部模板进行匹配6. 找到匹配的模板 后端类7. 动态创建后端类的实例8. 返回处理结果9. 返回响应数据10. HTTP响应最后你可以在后端处理类如CL_REST_SAMPLE_CAR的内部通过GET_URI_ATTRIBUTE(ID)这样的方法来提取 URL 路径中的{ID}参数值。
IF_REST_APPLICATION原理
IF_REST_APPLICATION原理IF_REST_APPLICATION实现路径匹配的核心原理是你预先定义一套“路由规则”即 URI 模板与后端 ABAP 处理类的绑定关系当客户端请求到来时SAP REST 框架中的“路由器”CL_REST_ROUTER会找出匹配度最高的那条规则自动创建对应的处理类实例然后由其处理该请求。下面我们来完整地拆解一下这个过程中的关键环节。 启动从 ICF 到 REST 应用整个流程始于 SAP 互联网通信框架 (ICF)。当客户端发送 HTTP 请求例如http://server/sap/bc/rest_cars/Cars/47时ICF 的请求会被你预先注册的 REST 处理类通常继承自CL_REST_HTTP_HANDLER捕获。这个通用的处理类会接管后续流程调用你需要实现的IF_REST_APPLICATION~GET_ROOT_HANDLER方法来获取整个 REST 应用的根路由器对象。这一步标志着从 ICF 的 http 层正式切入了专门的 REST 处理框架。️ 定义注册 URI 模板与后端类接下来你需要在一个继承自CL_REST_HTTP_HANDLER的子类中实现IF_REST_APPLICATION~GET_ROOT_HANDLER方法在其中完成最核心的路径匹配规则定义METHOD if_rest_application~get_root_handler. DATA(lo_router) NEW cl_rest_router( ). 注册路径模板 /Cars 到后端类 CL_REST_SAMPLE_CARS lo_router-attach( iv_template /Cars iv_handler_class CL_REST_SAMPLE_CARS ). 注册带参数和正则表达式的模板 lo_router-attach( iv_template /Car/{ID:[1-9][0-9]*} iv_handler_class CL_REST_SAMPLE_CAR ). ro_root_handler lo_router. ENDMETHOD.上面这段代码的逻辑在于创建路由器首先创建一个CL_REST_ROUTER对象它是整个路径匹配的执行中枢。绑定通过反复调用ATTACH方法将URI 模板IV_TEMPLATE和后端 ABAP 处理类名IV_HANDLER_CLASS紧密绑定起来。 匹配路径如何找到后端类CL_REST_ROUTER的工作就是根据请求的 URI 找到正确的处理器。SAP REST 库支持三种由简单到复杂的 URI 模板类型静态模板 (Static Templates)这是最直接的匹配方式。只有当请求的路径与模板字符串完全一致时才会被匹配。代码示例lo_router-attach( iv_template /Cars ... )匹配路径仅匹配.../Cars带属性的模板 (With URI Attribute)使用{属性名}作为占位符匹配该位置上的任意内容。代码示例lo_router-attach( iv_template /Cars_history/{MANUFACTURER} ... )匹配路径可以匹配.../Cars_history/ferrari也可以匹配.../Cars_history/maserati。带正则表达式的模板 (With URI Regular Expression Attribute)这是功能最强的模式允许用ABAP 正则表达式来精确控制匹配范围和格式。代码示例lo_router-attach( iv_template /Car/{ID:[1-9][0-9]*} ... )匹配路径可以匹配.../Car/1也可以匹配.../Car/47但由于正则[1-9][0-9]*的限制.../Car/0将无法匹配。处理路径冲突为了避免冲突CL_REST_ROUTER会使用一个高效的排序算法来决定最终使用哪个处理类。该算法会优先选择**“文字字符”**不是用{}包裹的变量部分最多的模板。例如对于一个请求cars/1/color模板A/cars/{ID}/color模板B/cars/{ID}/{TYRE}匹配算法会计算每个模板的精确文字字符数模板A包含文字/cars/、/color共6个c a r s /和c o l o r。模板B包含文字/cars/共1个。计算得出模板A 胜出因为它能更精确地描述这个请求。这确保了最相关的后端类会被优先调用。 执行实例化与处理当CL_REST_ROUTER找到最佳匹配的模板后框架会动态创建一个该后端处理类iv_handler_class的新实例。请求分发路由器会调用这个处理类实例的HANDLE方法并将 REST 请求对象IO_REQUEST和响应对象IO_RESPONSE作为参数传入。资源处理最后后端处理类如CL_REST_RESOURCE的子类中的对应方法如GETPOST被执行生成响应内容。 交互流程总结整个流程可以概括为下图所示的交互流程后端处理类应用类(IF_REST_APPLICATION)路由器(CL_REST_ROUTER)ICF框架REST 客户端后端处理类应用类(IF_REST_APPLICATION)路由器(CL_REST_ROUTER)ICF框架REST 客户端路由器存储了URI模板 - 后端类的映射关系1. HTTP请求 (e.g., GET /sap/bc/rest_cars/Cars/47)2. 调用 GET_ROOT_HANDLER()在方法内部构建并返回 CL_REST_ROUTER实例3. 返回配置好的路由器实例 (ro_root_handler)4. 将请求路由信息发送给路由器执行匹配5. 解析请求路径与内部模板进行匹配6. 找到匹配的模板 后端类7. 动态创建后端类的实例8. 返回处理结果9. 返回响应数据10. HTTP响应最后你可以在后端处理类如CL_REST_SAMPLE_CAR的内部通过GET_URI_ATTRIBUTE(ID)这样的方法来提取 URL 路径中的{ID}参数值。
