�ݺ�ߣshows by User: TedEpstein

�ݺ�ߣshows by User: TedEpstein / http://www.slideshare.net/images/logo.gif �ݺ�ߣshows by User: TedEpstein / Thu, 23 Aug 2018 20:17:46 GMT �ݺ�ߣShare feed for �ݺ�ߣshows by User: TedEpstein OpenAPI v.Next - Events, Alternative Schemas & the Road Ahead /slideshow/openapid-vnext-openapi-vnext-events-alternative-schemas-the-road-ahead/111194718 openapiv-180823201746
-- Presented at KCDC 2018 -- The OpenAPI Specification, already the most widely used REST API description language, is growing fast, and evolving to meet the challenges that come with broad adoption in a dynamic and diverse API ecosystem. In this session, we'll get up to speed with the latest developments in the OpenAPI spec, the tools ecosystem and member community. We'll show highlighted features of last year's major 3.0 release, dive into the new design capabilities currently in progress, and discuss the evolving roadmap for 3.x, 4.x and beyond.]]>
-- Presented at KCDC 2018 -- The OpenAPI Specification, already the most widely used REST API description language, is growing fast, and evolving to meet the challenges that come with broad adoption in a dynamic and diverse API ecosystem. In this session, we'll get up to speed with the latest developments in the OpenAPI spec, the tools ecosystem and member community. We'll show highlighted features of last year's major 3.0 release, dive into the new design capabilities currently in progress, and discuss the evolving roadmap for 3.x, 4.x and beyond.]]> Thu, 23 Aug 2018 20:17:46 GMT /slideshow/openapid-vnext-openapi-vnext-events-alternative-schemas-the-road-ahead/111194718 TedEpstein@slideshare.net(TedEpstein) OpenAPI v.Next - Events, Alternative Schemas & the Road Ahead TedEpstein -- Presented at KCDC 2018 -- The OpenAPI Specification, already the most widely used REST API description language, is growing fast, and evolving to meet the challenges that come with broad adoption in a dynamic and diverse API ecosystem. In this session, we'll get up to speed with the latest developments in the OpenAPI spec, the tools ecosystem and member community. We'll show highlighted features of last year's major 3.0 release, dive into the new design capabilities currently in progress, and discuss the evolving roadmap for 3.x, 4.x and beyond. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/openapiv-180823201746-thumbnail.jpg?width=120&height=120&fit=bounds" /> -- Presented at KCDC 2018 -- The OpenAPI Specification, already the most widely used REST API description language, is growing fast, and evolving to meet the challenges that come with broad adoption in a dynamic and diverse API ecosystem. In this session, we'll get up to speed with the latest developments in the OpenAPI spec, the tools ecosystem and member community. We'll show highlighted features of last year's major 3.0 release, dive into the new design capabilities currently in progress, and discuss the evolving roadmap for 3.x, 4.x and beyond.

OpenAPI v.Next - Events, Alternative Schemas & the Road Ahead from Ted Epstein

]]> 780 6 https://cdn.slidesharecdn.com/ss_thumbnails/openapiv-180823201746-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 RAPID - Building a highly usable API Design language with XText /slideshow/rapid-building-a-highly-usable-api-design-language-with-xtext-45761100/45761100 reprezendslxtextdaypublic-150312111904-conversion-gate01
The challenge: Create a highly readable, user-friendly design language for REST APIs, suitable for use by cross-functional enterprise teams. The toolkit: XText language framework for Eclipse IDE. The result: RAPID -- the Resource API Design language, used in RepreZen API Studio. In this presentation, RepreZen's Tanya Fesenko and Ted Epstein show why they decided to create a new API language in this already crowded space, and how they differentiated by raising the bar on usability. This presentation demonstrates to XText language developers some of the techniques required to build this kind of language.]]>
The challenge: Create a highly readable, user-friendly design language for REST APIs, suitable for use by cross-functional enterprise teams. The toolkit: XText language framework for Eclipse IDE. The result: RAPID -- the Resource API Design language, used in RepreZen API Studio. In this presentation, RepreZen's Tanya Fesenko and Ted Epstein show why they decided to create a new API language in this already crowded space, and how they differentiated by raising the bar on usability. This presentation demonstrates to XText language developers some of the techniques required to build this kind of language.]]> Thu, 12 Mar 2015 11:19:04 GMT /slideshow/rapid-building-a-highly-usable-api-design-language-with-xtext-45761100/45761100 TedEpstein@slideshare.net(TedEpstein) RAPID - Building a highly usable API Design language with XText TedEpstein The challenge: Create a highly readable, user-friendly design language for REST APIs, suitable for use by cross-functional enterprise teams. The toolkit: XText language framework for Eclipse IDE. The result: RAPID -- the Resource API Design language, used in RepreZen API Studio. In this presentation, RepreZen's Tanya Fesenko and Ted Epstein show why they decided to create a new API language in this already crowded space, and how they differentiated by raising the bar on usability. This presentation demonstrates to XText language developers some of the techniques required to build this kind of language. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/reprezendslxtextdaypublic-150312111904-conversion-gate01-thumbnail.jpg?width=120&height=120&fit=bounds" /> The challenge: Create a highly readable, user-friendly design language for REST APIs, suitable for use by cross-functional enterprise teams. The toolkit: XText language framework for Eclipse IDE. The result: RAPID -- the Resource API Design language, used in RepreZen API Studio. In this presentation, RepreZen's Tanya Fesenko and Ted Epstein show why they decided to create a new API language in this already crowded space, and how they differentiated by raising the bar on usability. This presentation demonstrates to XText language developers some of the techniques required to build this kind of language.

RAPID - Building a highly usable API Design language with XText from Ted Epstein

]]> 1664 2 https://cdn.slidesharecdn.com/ss_thumbnails/reprezendslxtextdaypublic-150312111904-conversion-gate01-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Data Modeling in the API Economy /TedEpstein/dmz-world-2014-data-modeling-in-the-api-economy dmzworld2014datamodelingintheapieconomy-141027125741-conversion-gate02
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.]]>
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.]]> Mon, 27 Oct 2014 12:57:40 GMT /TedEpstein/dmz-world-2014-data-modeling-in-the-api-economy TedEpstein@slideshare.net(TedEpstein) Data Modeling in the API Economy TedEpstein 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. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/dmzworld2014datamodelingintheapieconomy-141027125741-conversion-gate02-thumbnail.jpg?width=120&height=120&fit=bounds" /> 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.

Data Modeling in the API Economy from Ted Epstein

]]> 4884 5 https://cdn.slidesharecdn.com/ss_thumbnails/dmzworld2014datamodelingintheapieconomy-141027125741-conversion-gate02-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 D-Factor: How Strong Is Your Data Contract? /slideshow/d-factor/39616095 d-factor-140928080703-phpapp02
Service APIs converse in data. But they vary greatly in how the expectations around that data are specified. As a client developer, I need to know and what kind of data I can send to your service, and what kind of data I can expect to get back. D-Factors, inspired by Mike Amundsen's H-Factor, are a way to characterize your API's data contract across different dimensions. Is it machine-readable? Is it technology-specific? Does it only specify a format, like XML or JSON, or does it include domain-specific business data types? Are these types private to your system, or standardized at some level? We'll look at some concrete API examples, and use the D-Factors as a scorecard to evaluate the data contract.]]>
Service APIs converse in data. But they vary greatly in how the expectations around that data are specified. As a client developer, I need to know and what kind of data I can send to your service, and what kind of data I can expect to get back. D-Factors, inspired by Mike Amundsen's H-Factor, are a way to characterize your API's data contract across different dimensions. Is it machine-readable? Is it technology-specific? Does it only specify a format, like XML or JSON, or does it include domain-specific business data types? Are these types private to your system, or standardized at some level? We'll look at some concrete API examples, and use the D-Factors as a scorecard to evaluate the data contract.]]> Sun, 28 Sep 2014 08:07:03 GMT /slideshow/d-factor/39616095 TedEpstein@slideshare.net(TedEpstein) D-Factor: How Strong Is Your Data Contract? TedEpstein Service APIs converse in data. But they vary greatly in how the expectations around that data are specified. As a client developer, I need to know and what kind of data I can send to your service, and what kind of data I can expect to get back. D-Factors, inspired by Mike Amundsen's H-Factor, are a way to characterize your API's data contract across different dimensions. Is it machine-readable? Is it technology-specific? Does it only specify a format, like XML or JSON, or does it include domain-specific business data types? Are these types private to your system, or standardized at some level? We'll look at some concrete API examples, and use the D-Factors as a scorecard to evaluate the data contract. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/d-factor-140928080703-phpapp02-thumbnail.jpg?width=120&height=120&fit=bounds" /> Service APIs converse in data. But they vary greatly in how the expectations around that data are specified. As a client developer, I need to know and what kind of data I can send to your service, and what kind of data I can expect to get back. D-Factors, inspired by Mike Amundsen's H-Factor, are a way to characterize your API's data contract across different dimensions. Is it machine-readable? Is it technology-specific? Does it only specify a format, like XML or JSON, or does it include domain-specific business data types? Are these types private to your system, or standardized at some level? We'll look at some concrete API examples, and use the D-Factors as a scorecard to evaluate the data contract.

D-Factor: How Strong Is Your Data Contract? from Ted Epstein

]]> 950 3 https://cdn.slidesharecdn.com/ss_thumbnails/d-factor-140928080703-phpapp02-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Canonical Modeling for API Interoperability /TedEpstein/canonical-modeling-for-api-interop canonicalmodelingforapiinterop-140618015134-phpapp02
]]>
]]> Wed, 18 Jun 2014 01:51:34 GMT /TedEpstein/canonical-modeling-for-api-interop TedEpstein@slideshare.net(TedEpstein) Canonical Modeling for API Interoperability TedEpstein <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/canonicalmodelingforapiinterop-140618015134-phpapp02-thumbnail.jpg?width=120&height=120&fit=bounds" />

Canonical Modeling for API Interoperability from Ted Epstein

]]> 1380 5 https://cdn.slidesharecdn.com/ss_thumbnails/canonicalmodelingforapiinterop-140618015134-phpapp02-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 https://cdn.slidesharecdn.com/profile-photo-TedEpstein-48x48.jpg?cb=1572737658 Ted Epstein, CEO of RepreZen, has been helping organizations simplify, unify, and harmonize their API designs for over 10 years. Ted leads the architecture of RAPID-ML, the first open source IDL to bring the power of collaborative data modeling to REST API design. Ted is co-organizer of the API-Craft NYC Meetup and has presented at conferences including QCon, EclipseCon, API-Craft, and Data Modeling Zone. http://RepreZen.com Areas of specialized expertise: * API Design, including REST and Hypermedia, Microservice Architecture, IoT device interfaces, enterprise data services and SOAP/RCP style APIs. * Enterprise architecture, including data strategy, integration architecture, governan... reprezen.com https://cdn.slidesharecdn.com/ss_thumbnails/openapiv-180823201746-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/openapid-vnext-openapi-vnext-events-alternative-schemas-the-road-ahead/111194718 OpenAPI v.Next - Event... https://cdn.slidesharecdn.com/ss_thumbnails/reprezendslxtextdaypublic-150312111904-conversion-gate01-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/rapid-building-a-highly-usable-api-design-language-with-xtext-45761100/45761100 RAPID - Building a hig... https://cdn.slidesharecdn.com/ss_thumbnails/dmzworld2014datamodelingintheapieconomy-141027125741-conversion-gate02-thumbnail.jpg?width=320&height=320&fit=bounds TedEpstein/dmz-world-2014-data-modeling-in-the-api-economy Data Modeling in the A...