Erik Wilde
|
Erik Wilde is Principal Consultant at CA Technologies, and serves as Director of Technologies at CA's API Academy. He is active in a variety of standardization communities, and mostly focuses on technology and design issues in the context of APIs and API ecosystems. |
|
| Title | Shared Data Dictionaries for REST |
|---|---|
| Level | Featured Talk or Five-In-Five |
| Abstract |
In protocol design, it is a common pattern to leave certain protocol slots up to evolution, and have a registry that keeps track of the well-known values for those slots. This so far does not seem to be a popular pattern for REST services. After briefly introducing the concept and the idea, my goal is to gather interest and feedback and see if this is a pattern that might be interesting as a general part of the REST toolbox and what that would entail. |
| Supplemental | The Use of Registries (I-D) |
| Title | Documenting REST |
|---|---|
| Level | Five-In-Five |
| Abstract | With the advent of Microservices, it seems more likely than ever that documentation will become a major issue with constantly growing service landscapes. Several documentation formats have been proposed and are in use. Is there anything else the REST landscape needs in order to manage large and diverse landscapes of services and their documentation? |
| Supplemental | Discussion Page: What is the Web's Surface? Sedola: GitHub Repo I-D: Link Relation Types for Web Services |
| Title | Avoiding Specification Waterfalls |
|---|---|
| Level | Five-In-Five |
| Abstract | As with code, specifications should be written in a way that is lightweight, fast, and allows a quick feedback cycle. Instead of secretly writing the great documentation that will satisfy all needs of everybody, make sure to handle documentation like code: Be quick, separate concerns, identify the parts that can be shared and reused, and share with anybody who might be interested as quickly as possible. What are good ways of doing this, and what are pitfalls to avoid? This proposal looks at how specification and documentation should tie in with new development methods such as microservices and other approaches focused on agility and quick feedback cycles. |
| Supplemental | TBD |