1 / 12

OData Design Principles

OData Design Principles. July 26, 2012. Build on HTTP, REST. OData is a RESTful HTTP Protocol Build on HTTP Entities modeled as Resources Relationships modeled as links CRUD = POST, GET, PUT/PATCH, DELETE OData is Hypermedia-Driven Service Document Edit Links Relationship Navigation

gasha
Download Presentation

OData Design Principles

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OData Design Principles July 26, 2012

  2. Build on HTTP, REST • OData is a RESTful HTTP Protocol • Build on HTTP • Entities modeled as Resources • Relationships modeled as links • CRUD = POST, GET, PUT/PATCH, DELETE • OData is Hypermedia-Driven • Service Document • Edit Links • Relationship Navigation • Actions/Functions in payload • Enables loose coupling between clients and services

  3. Leverage Existing Formats • Build on existing Formats • ATOM, JSON, XML • Leverage built-in functionality appropriate to format where present • ATOM links, ids, etc. • Leverage extensibility for functionality not part of format • Namespaces for control data, conventions

  4. Model Driven • The Model defines the Contract • Defines Entity Sets, Entity Types, Functions • Set of possible valid common requests are derived from the model according to well defined semantics and conventions for querying, updating, and invoking operations • Enabled client query string building • Defines result shapes • Enables codegen of strongly typed objects at design time • Improves semantic interoperability while providing the client the most flexibility in the requesting desired data

  5. Simplicity is Key • Make it easy to implement over a broad variety of data sources • Incremental work for more advanced functionality • Conventions and semantics over a well defined model, common tools and libraries should make it easier to implement than defining a custom RESTful protocol.

  6. Client Focused • Define a simple to consume model that guides the client experience • Relationships rather than Foreign Keys • Inheritance rather than joins or descriminator fields • De-normalize as appropriate

  7. Consistency • Consistency across the interface facilitates understanding and makes it easier to reuse code • Applying common principles makes the interface predictable • Principle of least astonishment • More advanced scenarios should not work differently than simple scenarios

  8. Reach over Rich • Make the common stuff available and simple across services for the greatest number of consumers • Don't try and define every possible feature of every underlying store • i.e., Don't try and implement all of TSQL

  9. Extensible • Support advanced/custom scenarios through Extensibility • Metadata annotations for metadata extensibility • Instance annotations for data extensibility • Functions for query extensibility • Actions for CUD/Operational extensibility • Leverage Format-specific Extensibility • Enable common, shared extensions for features outside of OData's core functionality

  10. Extensions are Well Behaved • Extensions should be “opt-in” • Unless the client does something different, behavior should be as defined in Core • Client libraries should not have to know about extensions to work correctly

  11. Extensions Compose Well • Specific extensions should use common extensions for common concepts • i.e., Analytics extensions should use common vocabularies for units, common display hints, etc.

More Related