(4) About Me

• Ph.D. in Communications Systems [http://dret.net/netdret/publications#wil97b] from ETH Zürich [http://www.ethz.ch/]
• Working on Web Architecture after writing the first Web Technology book [http://dret.net/netdret/publications#wil98]
• While at UC Berkeley, working on Service Models for Open Government [http://dret.net/netdret/publications#wil09g]
• While at EMC, working on transforming software products into service platforms
• While at Siemens, working on using IoT to build WoT (APIs for Things)
• Joined CA [http://www.ca.com/]'s API Academy [http://www.apiacademy.co/] in May 2016 and now all about API Design and Strategy
• Active in the usual places such as Twitter [http://twitter.com/dret], GitHub [http://github.com/dret], flickr [https://www.flickr.com/photos/dret/], and my blog [http://dret.typepad.com/dretblog/]

(5) API Academy

• Global Team working on API Strategy and Design topics
  • Matt McLarty [http://www.apiacademy.co/team_member/matt-mclarty/] (Vancouver)
  • Mike Amundsen [http://www.apiacademy.co/team_member/mike-amundsen/] (Cincinnati)
  • Ronnie Mitra [http://www.apiacademy.co/team_member/ronnie-mitra/] (London)
  • Erik Wilde [http://www.apiacademy.co/team_member/erik-wilde/] (Zürich)
• Evangelizing ideas and technologies
  • Speaking (conferences, events)
  • Teaching (workshops, bootcamps)
  • Writing (blogs, articles, books)
  • Doing (side projects on API-related topics)
  • Standardizing (participating in specification work)

(6) Microservice Architecture

• Microservice Architecture: Aligning Principles, Practices, and Culture
• Authored by [http://www.apiacademy.co/microservice-architecture-the-oreilly-book/] API Academy [http://www.apiacademy.co/] members Irakli Nadareishvili, Ronnie Mitra, Matt McLarty, and Mike Amundsen
  • Get electronic version for free courtesy of CA Technologies [http://transform.ca.com/API-microservice-architecture-oreilly-book.html]
  • Get a hardcopy version [http://shop.oreilly.com/product/0636920050308.do]

(8) MSA and the API Landscape

(9) Internet of Things

(11) Activity Streams 1.0

• Developer effort to interconnect social networks
  • Counter-intuitive given then walled garden nature of most social networks
  • Even the social giants need proper plumbing between their services
• Simple and informative standard that was implemented but never (fully) documented
  • Some parts of the specification did not see good support in implementations
• Enterprise 2.0 customers demand stable and official standards
  • Social Enterprise Platforms are essentially integration platforms
  • Only robust and open models turn them into good IT solutions

(12) Activity Streams 2.0

• Activity Streams 1.0 [Activity Streams 1.0 (1)] were successful but not a very solid specification
• Social Networks are increasingly important for Enterprise IT
  • Enterprises slowly but increasingly understand the necessity for loose coupling
  • Use a protocol to interconnect heterogeneous systems
• Large Enterprise IT providers have pushed for AS to become more mature
  • IBM uses AS for interconnecting products for application lifecycle management [http://en.wikipedia.org/wiki/Application_lifecycle_management]
  • SAP uses AS in their enterprise collaboration tools
  • Customers demand for those platforms to be open and extensible
• AS2 is now being standardized in the W3C [http://www.w3.org/]'s Social Web WG [http://www.w3.org/Social/WG]
  • Activity Streams 2.0 [http://www.w3.org/TR/activitystreams-core/] and Activity Vocabulary [http://www.w3.org/TR/activitystreams-vocabulary/]

(14) AS needs Vocabularies

• AS is about activities and needs shared understanding
• Basic AS statement: Erik added a picture to Flickr
  • Actor: Erik
  • Verb: add
  • Object: picture URI [https://www.flickr.com/photos/dret/15433487108/]
  • Target: Flickr stream URI [https://www.flickr.com/photos/dret/]
• AS mixes three ways of how these concepts can be identified
  • By Value: The actor's name is Erik (good for simple rendering)
  • By Registry Reference: The well-known verb is add [https://www.w3.org/TR/activitystreams-vocabulary/#dfn-add] (good for shared meaning)
  • By URI Reference: Erik's Flickr Photostream [https://www.flickr.com/photos/dret/] (good for extensibility)

(15) Use, Extend, or Define?

• AS has three levels of verb expressivity

1. Using a well-known verb in the way how it has been defined
   • Erik just added something to an existing resource.
2. Extending a well-known verb in ways that make sense for those knowing the extension
   • For those who know and care, here is additional info about the camera.
3. Defining new verbs which do not mean anything for those not knowing them
   • Erik just edited the picture he added earlier.

(16) Finding/Using Vocabularies

• There is no centralized registry of AS vocabularies
  • The AS core specification only defines the general activity model [https://www.w3.org/TR/activitystreams-core/#model]
  • The AS vocabulary [https://www.w3.org/TR/activitystreams-vocabulary/] defines a set of well-known verbs
  • AS activities may use verbs other than the well-know ones
  • Extensions [https://www.w3.org/TR/activitystreams-core/#extensibility] can use strings or URIs as verbs (the difference is unclear)
• Everybody is free to define their own snowflakes
  • Network effect gains depend on agreement on the level of shared understanding
  • Only invent something if you absolutely have to

(17) Adapting Vocabularies

• Consider this when designing the activities for your course project!
• Reuse an existing activity type (they are loosely defined)
• Add facets to it that you need to satisfy your use case
• Adapting without hijacking is the litmus test of proper reuse
  • If somebody does not support your extensions, does it still make sense?
  • If this test cannot be satisfied, it is better to invent something new

(18) Quantified Self and Health

• Using data from wearables to support personal well-being and health
  • Producers: Wearables (e.g., activity trackers), general-purpose devices (e.g., activity-enabled smartphones), lab visits
  • Transformers: Consuming available data and distilling reports
  • Consumers: Users, health coaches, doctors (different granularity of consumption)
• Data production should be independent of specific devices
  • Exercise Data Format (EDF) [https://github.com/dret/exercise/tree/master/EDF] as a very simple standard for exercise data
  • The resources are linked from activities and use a different media type

(19) Do You Know What HIIT Is?

• Exercise types are considered relevant but not central
  • Nike Fuel [https://github.com/dret/exercise/blob/master/types/API/nikefuel.md] thinks HIIT is a thing
  • Even Wikipedia thinks it is a thing [http://en.wikipedia.org/wiki/High-intensity_interval_training]
• It is possible to transform proprietary into unified types
  • There is a long list of (currently 468) exercise types [https://github.com/dret/exercise/blob/master/types/overview.md]
  • Consumers are mostly not interested which device/service created the exercise data
  • A transformer consumes the proprietary types and transforms them into unified types
• A typical pattern of open and extensible system
  • Define a minimal but useful model for representing what the system is all about
  • Make this model extensible and open so that it can evolve without breaking existing components

(21) Evolving Value Sets

• Many business documents have evolving value sets
  • Hard-coding the value set is the simplest way
  • Every time the value set changes, the API changes
• Some of these value sets have utility across various services
  • Decoupling value sets from APIs decreases dependencies across services
• Registries are a well-known pattern for API-minded organizations
  • IETF [http://ietf.org/] has ~2000 registries managed by IANA [http://www.iana.org/protocols]
  • W3C [http://www.w3.org/] has no registry system but some specifications are creating their own [https://github.com/dret/RegMan/blob/master/W3C.md]
  • Considering the use of registries [http://tools.ietf.org/html/draft-wilde-registries] should be a general API design pattern

(22) Language Identification

• Language is a concept used across business documents
• Internet/Web language identification relies on language tags
  • RFC 5646 [http://tools.ietf.org/html/rfc5646] defines the syntax of language tags: en-US
• The language registry [http://www.loc.gov/standards/iso639-2/] is operated by ISO/LoC
  • The list of allowed values is defined by the current registry contents
• The country registry [https://www.iso.org/obp/ui/#search] is operated by ISO
  • The list of allowed values is defined by the current registry contents

(24) Scalable Protocol Design

• Use protocols and/or patterns instead of building snowflakes
• Diverse ecosystems create specific challenges for protocols/services
• Separating stable/evolving parts can make a big difference

(25) Thanks! Q&A

• Me: http://dret.net/netdret/ [http://dret.net/netdret/]
• Slides online: dret.net/lectures/nordic-apis-2016/ [http://dret.net/lectures/nordic-apis-2016/]
• Slide sources: dret/lectures [http://github.com/dret/lectures/tree/master/nordic-apis-2016] on GitHub [http://github.com/]