Ted Epstein
 |
|
Ted Epstein, Founder & CEO of ModelSolv, has over 20 years of experience in commercial and enterprise software development, and has been working on model-oriented solutions for API design and large-scale software integration since 2006. ModelSolv is a software provider and consultancy providing innovative technologies and solutions in APIs, data integration and SOA governance. Ted is co-organizer of the API-Craft NYC Meetup and has presented on API design and SOA integration at conferences including QCon, EclipseCon, API-Craft, and Data Modeling Zone.
| Title | RepreZen : Next-Generation API Design Workbench |
|---|---|
| Level | Extended Talk |
| Abstract |
RepreZen is an API Design Workbench built on the Eclipse platform. We'll show how RepreZen integrates API description, documentation, visualization, code gen and mocking, with an emphasis on shared data definitions. |
| Title | D-Factors: How strong is your data contract? |
|---|---|
| Level | Five-In-Five |
| Abstract |
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. |
| Supplemental | |
| Slides | http://www.slideshare.net/TedEpstein/d-factor |
| Title | A common metamodel for API definition |
|---|---|
| Level | Five-In-Five |
| Abstract |
API description languages like Swagger, API Blueprint, RAML, and others are becoming more essential to the API design process. In the foreseeable future, we probably won't see one clear winner. That's probably good, because there's a lot of room for innovation in this area. But it means that tooling, libraries and utilities designed to produce or consume one of these formats won't work with others. I propose that we work towards a common core of API description constructs that can be easily shared and translated across these formats. |
| Slides |