Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
Canonical Models for API Interoperability
Next
Download to read offline and view in fullscreen.

Share

Data Modeling in the API Economy

Download to read offline

REST APIs converse in data, and present a new idiom for organizing, exposing and exchanging data. There is a need to bring API design into the canon of modeling methods, and to incorporate data modeling as an essential component of this practice.

In this session, we will explore data models, data types and relationships as they relate to the common language of APIs. We will examine the current state of API modeling languages, graphical representation and modeling tools.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Data Modeling in the API Economy

  1. 1. Data Modeling in theAPI Economy PRESENTATION TO DATA MODELING ZONE, OCTOBER 2014 TED EPSTEIN, FOUNDER AND CEO MODELSOLV, INC. COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 1
  2. 2. All Eyes on APIs Paradigm shift with integration architecture, happening on two fronts: ◦REST as a recommended architectural style for internal services ◦Emergence of the API Economy COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 2
  3. 3. Internal REST Web-Style REST APIs are replacing SOAP for internal services. REST brings some useful design constructs for data-oriented APIs. REST is another wave of change in integration architecture ◦New trends bring new projects, modernization programs ◦A chance to improve on whatever we did before. ◦In this case, a chance to improve on SOA We need you! ◦Large scale integration needs data modelers! ◦We need to make the case for that, and get our IT organizations on a better path. ◦This talk will help get you started. COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 3
  4. 4. Emergence of the API Economy APIs have entered the mainstream of business and marketing awareness. Business can profit from APIs ◦As products and services. ◦As sales channels. ◦As points of customer engagement. COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 4
  5. 5. Massive Integration on Web and Mobile Everything integrating with everything else ◦Mashups ◦Common Services ◦Identity (Google, Facebook, Twitter, OpenID) ◦Transactions (PayPal, Google Wallet, Amazon Payments) ◦Location (Google Maps) ◦Document Sharing (Dropbox, Google Drive, SkyDrive) ◦Social (LinkedIn, Facebook, Twitter) COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 6
  6. 6. Integration Trends in Business and Government Cloud/SaaS Big Data Mobility Internet of Things Open Government COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 7
  7. 7. Mapping the Service Landscape COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 8
  8. 8. Internal and External Services Internal: We're somewhere on the REST adoption curve. ◦REST is the new SOA ◦No, it's an evolution of SOA ◦No, it's different, for this reason or that reason ◦Just don't call it SOA, because we don't like SOA ◦Fine, but it's still the new SOA ◦... and that's OK. Really. External: We're jumping on the API bandwagon. ◦May be headed by marketing ◦May be a separate technology team COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 9
  9. 9. Meeting in the Middle COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 10 source: http://www.soatothecloud.com/ There is no hard line: ◦We know that some private APIs will become public. ◦We don’t know which ones, or when. ◦We should be converging towards a common architecture for internal & external services.
  10. 10. What's govgot to do with it? Why do service APIs need “governance”? APIs are data conduits: ◦Services account for a significant portion of data flow Major technology initiatives are integration-intensive: ◦Mobile, Big Data, Cloud Computing /SaaS ◦Regulatory compliance Integration is the #2 challenge in Mobile and SaaS: ◦#1 is data security, #2 is integration COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 11 sources: MuleSoftand SnapLogicsurveys
  11. 11. Why is integration such a headache? Our systems are not speaking the same language. Every time a new team builds a new API, the IT landscape gets more complex. Billions spent on remedial solutions to aggregate disparate data, but we have a leaky roof. ◦Increasing complexity ◦Poor data quality ◦High integration cost ◦Slow time to market COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 12
  12. 12. What are we doing to stop these leaks? This is why data modelers need to get involved. We need unified canonical data models in our APIs. We need data quality constraints. Governance and Collaboration: two complementary paths to convergence. COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 13
  13. 13. REST Standards - Exploring the Stack COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 14
  14. 14. A Simple Data Model structureTaxFilingid : stringyear : gYearnetTax: decimalcurrency : stringtaxpayer : referencetoPersonstructurePerson taxpayerID: stringlastName: stringfirstName: stringaddresses : referencetoAddress* structureAddress street1 : stringstreet2 : stringcity : stringstateOrProvince: stringpostalCode: string COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 15
  15. 15. REST: An Architectural Style Some Essential Modeling Constructs: ◦Resources ◦Identifiers ◦Representations ◦Media Types ◦Methods ◦Hyperlinks COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 16
  16. 16. Fielding Disclaimer Strict REST vs. REST in Practice ◦URIs: opaque vs. transparent ◦Out-of-Band Information: media types, link relations vs. documentation ◦Processing Model: hypertext-driven vs. client-driven http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 17
  17. 17. Data Model as Resource Model COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 18 CollectionResource Data Type ObjectResource
  18. 18. HTTP Some Essential HTTP Modeling Elements: ◦URIs ◦Methods ◦Headers ◦Status Codes COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 19
  19. 19. REST/HTTP Resource Model COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 20 URI Template Method Request Response Status Code
  20. 20. Media Types About Media Types ◦MediaType(Resource) --> Representation ◦Appears in the content-type HTTP header ◦Used for content negotiation ◦Standard media types registered at: http://www.iana.org/assignments/media-types/media-types.xhtml COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 21
  21. 21. Low-Level Media Types Essentially Wire Formats ◦Technology-specific ◦Domain-neutral Examples: ◦application/xml ◦application/json many others ◦text/html ◦image/jpeg ◦application/protobuf ◦… COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 22
  22. 22. Generic Structured Media Types What are they? ◦Data-oriented media types a level above basic wire formats ◦Many of these basic formats are not hypermedia-aware ◦Intended to express generic structured data, but with some additional abstractions: Hyperlinks, embedded representations, collections, items… ◦Different media types will emphasize different things COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 23
  23. 23. HAL COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 24
  24. 24. Sidebar: Hyperlinks ◦Hyperlinks make REST genuinely different. ◦Hyperlinks are your friend. ◦A better way to model relationships ◦Tends to de-emphasize big, deeply nested messages ◦Helps neutralize some of the perspective mismatch problem ◦Hides identifiers in hyperlinks ◦Isn't that expensive? ◦Cache can go a long way ◦When to embed vs. hyperlink: ◦For network efficiency (even with caching) ◦For client developer convenience, if the embedded data will most often be required ◦For encapsulation (Think DDD Composites) COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 25
  25. 25. Hyperlinked Resource Model COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 26 Hyperlink
  26. 26. Domain-Specific Metadata Options ◦Domain-Specific Media Types (Sun Cloud, Atom) ◦Schemas (XSD, JSON, etc.) ◦Profiles ◦Microformats ◦Documentation COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 27
  27. 27. Diagram with Domain-Specific Data COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 28
  28. 28. Sidebar: Schemas and REST A cultural issue: uncomfortable relationship between REST and formal domain-specific data contracts. XML Schema was a sore spot for SOA. Domain-specific data contracts present a dilemma for strict REST: ◦Out-of-band information is supposed to be concentrated in media types and link relations, ◦... but we don't want an explosion of media types. REST is silent on the question of what to do with domain-specific data. REST is silent on whether your payload can or should include a schema. An opinionated perspective: ◦There's always a schema, whether you document it or not. ◦There are new options (JSON Schema, technology-independent schemas). ◦Defining a data contract formally just makes sense, much of the time. COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 29
  29. 29. API Description Languages Options ◦Swagger ◦API Blueprint ◦RAML What they have in common ◦Allow modeling of resources, data, methods, links, etc. ◦Public domain specifications, open-source web-based tooling. ◦Generate interactive documentation / testing sandbox. ◦Integration libraries and code generators. ◦Highly recommended as learning tools, to help you explore how REST APIs are put together. COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 30
  30. 30. Beyond REST as a Wrapper COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 31
  31. 31. REST as a Silver Bullet The fantasy: ◦Exactly one resource for everything ◦The golden source is the only source ◦Everything perfectly hyperlinked The Reality ◦One size fits none ◦Need to balance centralization and agility ◦Different APIs for different functions COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 32
  32. 32. API as a Domain Model COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 33
  33. 33. API as a workflow model Affordances: ◦Action-oriented hyperlinks ◦Transaction-oriented resources ◦Navigational links to related resources Workflow and affordances vary by service context. Variations often require different APIs for different clients. COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 34
  34. 34. API as a Client View It’s not necessarily just a domain model dump. It’s the domain as the client sees it: Respect the Client’s vocabulary Points of Divergence: ◦Property subsets ◦Flattening ◦Renaming ◦Change of perspective. ◦Reification: example, refund COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 35
  35. 35. Canonical Models and Variations There’s acommon theme (canon) underneath these variations. See how far you can go with canonical models and realizations: ◦Can we describe the theme and variations separately? ◦Can we model the variations as adaptations, augmentations of the theme? ◦If so, maybe we don’t needAPI-specific data types COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 36
  36. 36. Realization: Property Subset COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 37 API requests or responses may only need a subset of properties defined in the canonical model. Realization model may specify a list of included properties.
  37. 37. Realization: Perspective COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 38 Message and resource structures project different views from the same logical data model Canonical model should support bi-directional references. Realization model should allow embedded or linked representations.
  38. 38. Realization: Metadata COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 39 Business Information Model Account ID Balance Margin Status Account Party ID Name Party 1 0..n Data Aspects · Deltas · Data Source · Data Security · Explicit Null Values ... Message Structure <party dataSource=“MSDB”> <partyId>123</partyId> <partyName xsi:nil=“true” nullValue=“Not Available” /> <accounts> <account dataSource=“A2” transType=“insert”> <accountId>XYZ</accountId> <balance xsi:nil=“true” isRestricted=“true” /> … </account> … </accounts> </party> APIs may need to augment essential data with descriptive metadata. Data aspects are cross-cutting concerns that may be woven together with canonical data as part of the interface realization.
  39. 39. Realization: Contextual Constraints <=$10MM Asset Class = Bond COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 40 Trade Services may have specific constraints that are not intrinsic to the data definitions. Realization model may specify constraints on requests or responses. Constraints may take different forms: range, subtype, logical expression, etc.
  40. 40. Conclusion: Get involved! We need your modeling skills. Done right, new API initiatives can have huge positive impact. Done poorly, they can actually make things worse. ◦Net Negative Contributing API(NNCAPI) ◦… or Convergence-Resistant API ;-) COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 41
  41. 41. Resources REST: ◦Basic REST in action: http://www.youtube.com/watch?v=7YcW25PHnAA ◦HTTP and REST: http://code.tutsplus.com/tutorials/a-beginners-guide-to-http-and-rest--net-16340 ◦REST API Design Principles: http://www.infoq.com/articles/rest-introduction ◦REST Idioms and Patterns: http://www.narwhl.com/ API Blogs ◦http://apievangelist.com ◦http://programmableweb.com COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 42
  42. 42. Resources (continued) Canonical Models: ◦http://www.slideshare.net/TedEpstein/canonical-modeling-for-api-interop ◦http://www.digitalml.com/resources/Service_Design_Forum API Description Languages ◦http://swagger.io/ ◦http://apiblueprint.org/ ◦http://raml.org/ ◦http://modelsolv.com/reprezen COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 43
  43. 43. Questions THANK YOU! ted.Epstein@modelsolv.com COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. 44
  • WenxinWu1

    Feb. 28, 2020
  • hdjebar

    Feb. 3, 2016
  • launchany

    Oct. 28, 2015
  • BarryMagaziner

    Aug. 9, 2015
  • LorenzoMoriondo

    Feb. 17, 2015
  • pgonyan

    Feb. 12, 2015
  • jhigginbotham

    Nov. 2, 2014

REST APIs converse in data, and present a new idiom for organizing, exposing and exchanging data. There is a need to bring API design into the canon of modeling methods, and to incorporate data modeling as an essential component of this practice. In this session, we will explore data models, data types and relationships as they relate to the common language of APIs. We will examine the current state of API modeling languages, graphical representation and modeling tools.

Views

Total views

4,752

On Slideshare

0

From embeds

0

Number of embeds

1,038

Actions

Downloads

64

Shares

0

Comments

0

Likes

7

×