Roundup #16: NET Standard 2.1, Endpoint Routing, Bullseye, API Spec Workflow

Here are the things that caught my eye this week.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

Follow @codeopinion

.NET Standard 2.1

This document describes the plan for .NET Standard 2.1, which includes the definition of its API surface.
We did a diff between .NET Core 2.1 and .NET Standard 2.0 to see which APIs that were added in .NET Core would be great candidates for inclusion in the standard.

Interesting to read some of the pros/cons for versioning and the decision to go with 2.1

Link: https://github.com/dotnet/standard/blob/master/docs/planning/netstandard-2.1/README.md

Endpoint Routing

We’re making a big investment in routing starting in 2.2 to make it interoperate more seamlessly with middleware. For 2.2 this will start with us making a few changes to the routing model, and adding some minor features. In 3.0 the plan is to introduce a model where routing and middleware operate together naturally. This post will focus on the 2.2 improvements, we’ll discuss 3.0 a bit further in the future.

Pretty nice to see this as I’ve been wanting this for some time now, hence blog post on generating links to routes outside of MVC .

Link: https://blogs.msdn.microsoft.com/webdev/2018/08/27/asp-net-core-2-2-0-preview1-endpoint-routing/

Bullseye

Bullseye is a .NET package for describing and running targets and their dependencies.

Bullseye can be used to write targets that do anything. It is not coupled to building .NET projects.

Really cool project that I just discovered by Adam Ralph .  Bullseye feels like a great and simple way to define some targets for doing tasks.  Feels very much like Cake without all the extra plugins.  Anyone using it already? Going to explore it more.

Link: https://github.com/adamralph/bullseye

Our API Specification Workflow

A year ago we started trying to figure out the best way to not just document HTTP APIs, but to leverage API specifications to avoid duplicating efforts on loads of similar-but-different tasks; maintaining Postman Collections, creating mocks, contract testing, payload validation, etc. To us, it felt like API developers were wasting a lot of time writing up the same logic over and over again. Listing endpoints, defining what fields should have what data, figuring out validation logic, writing up examples, doing this all over and over again in loads of different formats, then — the few folks that have enough time and interest —would write loads of tests to make sure all these different formats were saying the same thing.

Link: https://engineering.wework.com/our-api-specification-workflow-9337448d6ee6

Follow @codeopinion