OData Basics: V2 vs V4
What is OData, and how do V2 and V4 differ at a high level?
OData is an open protocol for building RESTful APIs over HTTP. V2 was designed around SAP's NetWeaver Gateway and Atom/XML payloads, while V4 is the OASIS standard built for JSON-first clients, cleaner URLs, and richer metadata. In interviews, lead with this: V2 is legacy SAP Gateway, V4 is the modern standard.
How does the metadata document differ between V2 and V4?
V2 metadata is Entity Data Model XML served at $metadata with heavy use of annotations like sap:label and sap:filterable. V4 metadata uses the same $metadata endpoint but expresses semantics through standard vocabulary annotations such as Org.OData.Measures.V1 and Org.OData.Capabilities.V1. V4 also supports JSON metadata via Accept: application/json.
Compare URL conventions for reading an entity in V2 vs V4.
V2 reads look like /sap/opu/odata/sap/ZSALES_SRV/Orders(42)?$format=json with parentheses around keys and a format query option. V4 drops the parentheses-only style for key predicates written as /Orders(42) too, but requires no $format since JSON is default. The real difference is in querying: V4 adds $search, $count=true inline, and $expand with nested $select.
Key takeaway: V2 defaults to XML and needs $format=json. V4 is JSON by default and standardizes capabilities that V2 vendors implemented inconsistently.
CRUD and Querying
How does creating an entity differ between the two versions?
Both use POST to the entity set, but V2 returns the created entity by default and V4 returns 204 No Content unless you send the Prefer: return=representation header. V4 also standardizes deep insert through a single POST with nested entities. Know this cold — interviewers love the Prefer header detail.
What is the difference in how batch requests work?
V2 batch uses multipart/mixed with changesets for transactional grouping of write operations. V4 keeps multipart/mixed but drops changesets in favor of atomicity groups and uses JSON batch format as an alternative. V4 batch also allows referencing results of earlier operations within the same batch via $0-style content IDs.
How do $filter and $expand compare across versions?
V2 supports $filter with a limited operator set and $expand with depth restrictions set on the Gateway service. V4 expands the filter function library (contains, startswith, date functions) and supports nested query options inside $expand, like $expand=Items($select=Name;$top=5). V4 also adds $apply for server-side aggregation.
What is $apply in V4 and why does it matter?
$apply brings aggregation to the URL: groupby, filter, and aggregate transformations run server-side, e.g. $apply=groupby((Region),aggregate(Revenue with sum as Total)). V2 had no equivalent — aggregation was done through separate analytical services or client-side code. This is a flagship V4 advantage for analytical apps.
How is paging handled in each version?
V2 uses $top and $skip for client-driven paging, plus server-driven paging via __next links in Atom feeds. V4 keeps $top/$skip but formalizes server-driven paging with @odata.nextLink annotations in JSON. V4 also adds $count=true to get the total count inline, while V2 required a separate $count or $inlinecount request.
Key takeaway: V4 query options are strictly more expressive — $apply, nested $expand, and inline $count cover most reporting needs without custom service code.
Service Modeling and SAP Landscape
How are V2 services built in SAP versus V4 services?
V2 services are built with transaction SEGW: define the data model, generate MPC/DPC classes, and reimplement CRUD methods in ABAP. V4 services in the SAP stack are typically exposed via CDS with @OData.publish or through CAP (Cloud Application Programming Model), which generates V4 services from CDS models automatically. SEGW is on-premise ABAP; V4 is the BTP/CAP world.
What is the role of annotations in each version?
In V2, SAP-specific annotations (sap:searchable, sap:sortable, sap:updatable) drive Fiori UI behavior and are embedded in metadata XML. In V4, UI annotations follow the standard UI vocabulary (@UI.LineItem, @UI.FieldGroup) and are served from the same metadata. CAP and RAP services emit V4 UI annotations from CDS source — one model, UI and protocol.
How does concurrency control differ?
V2 relies on ETags in the __metadata of Atom entries, with If-Match headers on updates. V4 standardizes ETags via @odata.etag annotations and the same If-Match/If-None-Match semantics, but additionally supports optimistic concurrency declared in the model. Functionally similar; V4 is just better standardized.
Can a V4 service be consumed from SAPUI5? Any version gotchas?
Yes — sap.ui.model.odata.v4.ODataModel is the standard model for V4, while sap.ui.model.odata.v2.ODataModel handles V2. The v4 model is request-driven with automatic batching of changes; there is no two-way binding in the classic sense. Mixing them in one app is discouraged — pick the model that matches your backend.
// V4 model in UI5 — note the groupId and auto batch behavior
var oModel = new ODataModel({
serviceUrl: "/odata/v4/sales/",
synchronizationMode: "None",
groupId: "$auto"
});Which version should new SAP projects use in 2026?
V4, without debate. SAP's strategic stack — CAP, RAP, and Fiori elements — generates V4 services. V2 remains only for maintaining existing Gateway services on S/4HANA on-premise. If an interviewer asks about migration, mention that there is no automatic converter: V2 MPC/DPC logic must be re-expressed in CDS/RAP or CAP.
Key takeaway: V2 = SEGW, XML-first, legacy maintenance. V4 = CDS/CAP/RAP, JSON-first, all new development. State this clearly and the interview is half won.
Error Handling and Functions
How do error responses differ between V2 and V4?
V2 errors come as Atom error XML or a verbose JSON error object with innererror details. V4 defines a single JSON error structure: code, message, target, and details array. V4 also standardizes in-band error details for batch operations. In both, SAP Gateway adds /iwbep/ error log tracing via transaction /IWBEP/ERROR_LOG for V2 services.
What are function imports in V2, and what replaced them in V4?
V2 function imports expose custom operations like GET /ApproveOrder?OrderId=1. V4 replaces them with actions (side-effecting, POST) and functions (side-effect-free, GET), bound or unbound to entities. Bound actions like POST /Orders(42)/Approve are the idiomatic V4 pattern and map cleanly to RAP/CAP action handlers.
Interviewing soon? Drop your toughest OData question in the comments.