Choosing Between OData V2 and V4

OData V2 and V4 are different versions of the OData protocol with different metadata vocabularies, payload details, query behavior and client expectations. In SAP, classic Gateway/SEGW services are strongly associated with V2, while RAP service bindings support modern V2 and V4 exposure patterns and Fiori Elements V4 is designed around OData V4. The important correction is that batch format is not a simple 'V2 uses multipart, V4 uses JSON' distinction in SAP Gateway: SAP's OData V4 batch documentation and current S/4HANA APIs commonly use multipart/mixed batch requests and changesets. Likewise, deep create is not unique to V4—classic SAP Gateway V2 services can implement deep insert through the OData Channel. V4 brings a newer standardized metadata/capability model and is the strategic fit for many new RAP scenarios, but feature selection must be based on the actual SAP service/runtime and consumer.

Use OData V4 when building new RAP services/Fiori Elements V4 applications and when the consumer supports the V4 contract and capabilities you need. Use V2 when maintaining existing SEGW/Gateway services, when a current Fiori/UI5 or third-party consumer is contractually tied to V2, or when the target SAP application exposes only V2. RAP can also expose services through V2 bindings where required, so protocol choice is a consumer/runtime contract decision rather than a judgment that one version is 'legacy-only'. Before migration, compare metadata annotations, batch/change-set behavior, draft support, client library compatibility and error payloads rather than assuming wire formats are interchangeable.

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 team builds a new RAP approval app and chooses an OData V4 UI service binding because the target Fiori Elements floorplan supports V4 and RAP draft/action semantics fit naturally. A separate external consumer still expects an established V2 metadata contract, so a V2-compatible service is retained for that consumer. During testing, a developer assumes the V4 batch request should be JSON and hand-builds a JSON batch payload; the SAP Gateway endpoint rejects it because that service expects multipart/mixed batch syntax. The fix is to follow the service's documented batch contract, not an internet generalization about OData versions.

OData V4 with RAP/Fiori Elements V4 is a strategic direction for new S/4HANA development, while OData V2 remains supported and widely used in existing Gateway and application APIs. S/4HANA can therefore contain both versions for valid reasons. Clean-core guidance is primarily about consuming released business services and avoiding unsupported core coupling; it does not require a blanket immediate replacement of every V2 service. Migrate when the target protocol/consumer benefits justify the contract change.

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.

Read service definition and service binding in RAP to see exactly where the V2/V4 choice is made mechanically. Read SEGW versus CDS based service exposure for the legacy side of the comparison. Read OData batch requests and deep inserts and etag and concurrency control in OData for the two areas where the wire-format differences cause the most production incidents. Read Fiori Elements versus freestyle Fiori and RAP draft handling to connect the protocol choice back to what the UI layer actually requires.