Data Services and APIs: REST, SOAP, OData, and GraphQL Publishing
What this domain tests
Publishing turns views and stored procedures into consumable APIs. Questions compare REST, SOAP, OData and GraphQL, and test how authentication, resource naming and limits are configured.
REST and SOAP
A REST service exposes selected views as resources; clients call them with HTTP GET and query parameters, and responses are JSON or XML. Authentication options include HTTP Basic and OAuth, and the service can publish an OpenAPI/Swagger description. SOAP services expose views as operations and generate a WSDL; the WSDL must be regenerated when the published signature changes. Both publish a view's output, so the view - not the base table - is the security boundary.
OData
OData 4 exposes a database as entity sets that BI tools understand natively, supporting $filter, $select, $top, $skip, $orderby and $expand. It is the right choice when the consumer already speaks OData; not every VDP function maps cleanly into OData expressions, so complex logic belongs in a view.
GraphQL
GraphQL publishes a single endpoint with a schema derived from the published views. Clients request exactly the fields they need, including nested relationships, which suits mobile and front-end consumers. Depth and complexity limits protect the server from expensive nested queries, and introspection exposes the schema.
Worked example
A mobile app needs customer data with a nested list of recent orders and only four fields. Reasoning: GraphQL fits because the client shapes the response and avoids over-fetching; publish the customer and orders views, define the relationship in the schema, and enforce authentication at the service. A BI tool needing ad-hoc filtering would instead get OData, and a legacy integration expecting a WSDL would get SOAP.
Traps that cost marks
- Publishing a base view where a masked or filtered view was intended.
- Forgetting that the WSDL or GraphQL schema must be refreshed after changing the view.
- Assuming all VDP functions translate into OData filter expressions.
- Omitting row limits, so a single API call can scan an entire view.