Choosing Between OData V2 and V4
OData V2 is the older protocol tied to SEGW and Fiori Elements V2 templates. OData V4 is the OASIS standard version that RAP generates natively, with richer $expand, JSON-based batch, and native deep insert. New RAP development should default to V4. V2 is kept only for legacy Fiori apps, existing SEGW services, or consumers that cannot handle V4's wire format.
This page compares OData V2 and OData V4 as they show up in day-to-day SAP development, focused on the practical differences that break code and UIs rather than the protocol specification. It covers where each version sits in the RAP and Gateway stack, a worked coexistence scenario, and the decision points an architect should walk through before picking one over the other.
Published 16 Sept 2026· 1,434 words
What it is
OData V2 and V4 are not just sequential version numbers on the same protocol, they are two different specifications with incompatible wire formats. V2 uses multipart/mixed MIME for batch requests, a separate metadata dialect built around sap: vendor annotations, and limited support for filtering or sorting inside an expanded navigation. V4 is the OASIS-ratified standard, uses JSON for $batch, supports deep insert and deep update as part of the base protocol rather than as a workaround, and expresses UI and behavior hints through standard capability annotations instead of sap: extensions. In SAP terms, V2 is the protocol behind classic SAP Gateway services built with SEGW and consumed by Fiori Elements V2 floorplans. V4 is the protocol RAP generates when a service binding of that type is created, and it is the only protocol Fiori Elements V4 floorplans speak. The confusion mostly comes from assuming annotations, batch payloads, or error handling carry over unchanged between the two, they do not.
When to use it
Use OData V4 for any new RAP business object, any new Fiori Elements app built on the V4 floorplans, and any scenario needing native draft handling, deep create, or filtered navigation properties without custom coding. Use OData V2 only when there is a real constraint pulling in that direction: an existing SEGW service under active maintenance, a legacy custom SAPUI5 app whose data layer is hardwired to V2 batch parsing and cannot be rewritten this release, or an external consumer whose client library has no V4 support. Reaching for V2 on a greenfield S/4HANA build because a team is more familiar with SEGW is a mistake that creates technical debt on day one, since the platform's tooling, draft handling, and clean-core extensibility model are all built around V4 and RAP.
How it fits the stack
Below the protocol sit CDS view entities and, for V4 services, RAP behavior definitions and implementations; for V2 services the equivalent layer is the DPC and MPC classes generated by SEGW, or a CDS view exposed through a projection with sap: annotations. Above the protocol sits the service binding, which is where the choice between V2 and V4 is actually made in a RAP scenario, followed by the consuming UI: Fiori Elements V2 templates and older freestyle SAPUI5 apps speak V2, Fiori Elements V4 templates and RAP-native draft UIs speak V4. OData V4 with RAP effectively supersedes the SEGW plus OData V2 combination for new development, though it does not remove V2 from the stack, both protocols coexist on the same gateway and can even expose the same underlying CDS data through separate bindings.
A worked example
A team owns a RAP business object for sales order approvals, implemented with a behavior definition and a managed transactional model. A new Fiori Elements V4 list report and object page is generated against this BO through a V4 service binding, giving native draft handling and inline create for line items without extra code. A separate legacy custom SAPUI5 app, built two years earlier against a SEGW service, still needs to read the same approval data because it has not been scheduled for a rewrite. Rather than forcing that app onto V4, a second service binding of type OData V2 is generated against a read-only projection of the same underlying CDS entities. The team quickly finds that the legacy app's manual batch-parsing code, written for V2's multipart/mixed format, works unchanged against the new V2 binding, but an attempt to reuse the same custom $batch helper against the V4 binding for a different app fails outright because the response comes back as JSON, not MIME parts. The two bindings are kept deliberately separate rather than shared.
How to choose
- Is this new RAP development or the continuation of an existing SEGW service. New RAP work should default to V4, there is rarely a business justification for choosing V2 on a fresh build.
- What can the consuming client actually parse. A custom SAPUI5 app, a third-party integration, or an old client library may only handle multipart batch and sap: annotations, forcing a V2 decision regardless of preference.
- Which Fiori Elements floorplan version the UI requirement calls for. The floorplan dictates the protocol, not the other way around, check this before designing the backend service.
- Does the scenario need native deep create, deep update, or draft handling. These are first-class in V4 and require custom coding in V2, a heavy cost if chosen late.
- What is the cost of running both protocols side by side long term versus migrating the V2 consumer. Coexistence is cheap technically but adds a second binding, a second metadata contract, and a second set of regression tests to maintain.
- Are there external or B2B consumers contractually tied to a V2 metadata contract. Changing that contract has consequences outside the SAP system and may force V2 to stay regardless of internal preference.
Common pitfalls
- Assuming $batch behaves the same way across versions. V2 batch is multipart/mixed, V4 batch is JSON. Custom code written to parse or construct one format silently breaks, or worse, silently succeeds with malformed data, against the other.
- Porting sap: vendor annotations from a V2 CDS projection into a V4 service and expecting the same UI behavior. V4 uses standard capability annotations, the sap: annotations are simply ignored, and the resulting Fiori Elements app loses functionality with no error raised.
- Expecting $expand with $filter or $orderby on a navigation to work in V2 the way it does in V4. It does not, and this is usually discovered only when a specific filtered list view returns unfiltered data or a syntax error at runtime, not at design time.
- Treating draft handling as a simple field to copy between versions. V2 draft implementations are hand built, V4 draft is native to RAP, and the two mechanics do not map onto each other without a rewrite.
- Custom error handling code written against V2's error response structure breaking against a V4 service, because the error payload shape differs between the two specifications.
- Switching a service binding's protocol type and not regenerating or clearing cached metadata, producing UI failures that look like an authorization problem but are actually a stale $metadata document.
- Testing nested $expand chains only against small data sets in a sandbox. Implicit joins generated by deep navigation in V4 can produce heavier SQL than the equivalent hand-written V2 read, and this only shows up under production data volumes.
ECC, S/4HANA and clean core
OData V4 paired with RAP is the strategic direction on S/4HANA and is what clean-core extensibility guidance points toward for new development. OData V2 built through SEGW is the classic approach, still functioning and still supported for existing services, but discouraged as a starting point for anything new. Some compatibility CDS views in S/4HANA continue to be exposed through V2 bindings purely to keep older Fiori apps working after an upgrade, not because V2 is preferred. The practical upgrade path is to extend existing functionality through RAP and a V4 binding rather than adding custom logic onto an aging SEGW service, and to plan a retirement date for V2 consumers rather than letting the two protocols coexist indefinitely by default.
Whose problem this is
The developer decides which service binding type to generate and writes the corresponding behavior implementation or DPC/MPC logic. The architect sets the protocol strategy for the landscape and decides how long V2 coexistence is tolerated. The functional consultant flags which Fiori floorplan or external integration constraint is driving the choice, since that requirement usually determines the protocol before any code is written.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-technical-topics/odata-v2-versus-odata-v4-for-sap-developersERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.