Build on HTTP REST OData is a RESTful HTTP Protocol Build on HTTP Entities modeled as Resources Relationships modeled as links CRUD POST GET PUTPATCH DELETE OData is HypermediaDriven Service Document ID: 1022930
Download Presentation The PPT/PDF document "OData Design Principles July 26, 2012" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
1. OData Design PrinciplesJuly 26, 2012
2. Build on HTTP, RESTOData is a RESTful HTTP ProtocolBuild on HTTPEntities modeled as ResourcesRelationships modeled as linksCRUD = POST, GET, PUT/PATCH, DELETEOData is Hypermedia-DrivenService DocumentEdit LinksRelationship NavigationActions/Functions in payloadEnables loose coupling between clients and services
3. Leverage Existing FormatsBuild on existing FormatsATOM, JSON, XMLLeverage built-in functionality appropriate to format where presentATOM links, ids, etc.Leverage extensibility for functionality not part of formatNamespaces for control data, conventions
4. Model DrivenThe Model defines the ContractDefines Entity Sets, Entity Types, FunctionsSet of possible valid common requests are derived from the model according to well defined semantics and conventions for querying, updating, and invoking operationsEnabled client query string buildingDefines result shapesEnables codegen of strongly typed objects at design timeImproves semantic interoperability while providing the client the most flexibility in the requesting desired data
5. Simplicity is KeyMake it easy to implement over a broad variety of data sourcesIncremental work for more advanced functionalityConventions 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 FocusedDefine a simple to consume model that guides the client experienceRelationships rather than Foreign KeysInheritance rather than joins or descriminator fieldsDe-normalize as appropriate
7. ConsistencyConsistency across the interface facilitates understanding and makes it easier to reuse codeApplying common principles makes the interface predictablePrinciple of least astonishmentMore advanced scenarios should not work differently than simple scenarios
8. Reach over RichMake the common stuff available and simple across services for the greatest number of consumersDon't try and define every possible feature of every underlying storei.e., Don't try and implement all of TSQL
9. ExtensibleSupport advanced/custom scenarios through ExtensibilityMetadata annotations for metadata extensibilityInstance annotations for data extensibilityFunctions for query extensibilityActions for CUD/Operational extensibilityLeverage Format-specific ExtensibilityEnable common, shared extensions for features outside of OData's core functionality
10. Extensions are Well BehavedExtensions should be “opt-in”Unless the client does something different, behavior should be as defined in CoreClient libraries should not have to know about extensions to work correctly
11. Extensions Compose WellSpecific extensions should use common extensions for common conceptsi.e., Analytics extensions should use common vocabularies for units, common display hints, etc.
12.