Spec-Driven APIs
Steve Konves

Great article! But I do have a couple issues.

First being that the spec design at the seam is not the first step. The spec can only be written after the the scope is defined. This can be done by first a story with scenarios. This may also include the need for an architectural outline of the limits of the domain.

Second is the use of run-time evaluation. The issue with run-time evaluation is in fact the overhead, but also another surface for attack. While the overhead may be small for 10..100…even 1000 concurrent connections, but as the workload gets heavier it will require more CPU cycles and depending on how the spec is defined, such as the spec being on a separate file, being loaded into memory. This will greatly be dependent on how this part of the system is built. While we do live in a time where memory is cheap, but I find CPU cycles to be expensive. Now the security issue, I feel that this method can create a new surface of attack. This will greatly depend on how the spec is loaded into the app.

I feel the solution is to extensively use strict behavior tests. And implement them during deployment, such as a CI system.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.