Getting Started with Zuplo, the Modern API Gateway API Gateways provide all sorts of really helpful functionality for APIs developers, covering things like rate limiting, authentication, network caching, and some of the newer ones will support server-side validation based on OpenAPI and/or JSON Schema. This is all awesome, but it usually happens through some web interface that's a long way away from the source code and gets easily confused when pull requests change things. I don't want to have to ask someone on the Infra team to remember to add my new endpoint to the API Gateway when they get back from holiday. I don't want to copy and paste the updated OpenAPI into a text box on a web interface every few weeks. That should all be powered by Git! Thankfully this is exactly what Zuplo is about. Zuplo's creators set out to make it feel native to developers, who increasingly expect to be able to do everything through their existing GitOps workflows, and are becoming less and less interested in configuring weird XML via SSH on servers they forgot how to work with. As you can tell I'm not a infrastructure person, but I'm going to have a go at setting up Zuplo, to see if a bog-standard software engineer + API designer/developer can get, and how easy it is. Sample Application

As somebody new to woodland creation and restoration, I have been learning quickly thanks to the advice of several experts in various fields. This information clashed with many of my preconceptions, and I see the same confusion perpetrated in print media and social media. Planting Close Together I have heard a lot of concern about the proximity of saplings being planted, where the concern is that every sapling will not have room to grow to its full potential. The truth is, not every sapling is going to reach maturity. Several things could go wrong: it could be eaten, suffer from drought, suffer from a warm spring followed by harsh cold snaps, it could be trampled by a deer, even slugs and insects can eat the leaves. You could spray pesticides everywhere and put up expensive fencing all over the countryside, but the more natural approach is to recreate what nature does: trees produce far more seeds than are expected to survive. From thousands of acorns only a few will find the right conditions to germinate, and they may well be in competition with each other, and other saplings nearby. When an area is “overstocked” with saplings, they can be “thinned out” in phases over time, until a healthy tree canopy exists - the first phase of creating a woodland. The alternative would be planting exactly the number of trees you hope for, and if anything goes wrong you’re just left with a field with some trees in it.

At first people used Spectral to tell them if they were writing valid OpenAPI. Then it was used to see if their API matched their API Style Guide. Now, thanks to the Spectral OWASP API Security ruleset, you can use Spectral to see if your API is making any common security blunders. What is the OWASP API Security Top 10? The Open Web Application Security Project (OWASP) is a nonprofit foundation that works to improve the security of software. They maintain open-source software projects, have hundreds of local chapters worldwide with tens of thousands of members, and they run education and training conferences. OWASP have complied lots of resources including what they consider to be the Top 10 mistakes being made in web applications in general. As API developers, we're a bit more interested in their newer API-specific project, the OWASP API Security Top 10 (2019). The API security top 10 covers the following topics: Broken Object Level Authorization

OpenAPI v3.1.0 has a bunch of great changes, solving problems like the subtle differences between JSON Schema objects and OpenAPI Schema objects, and adds support for Webhooks. Upgrading tooling can be tricky, but this should be a lot easier than the jump from v2 to v3.0. To reduce the workload we've put together some convenient resources for tooling developers, to provide test cases, examples, and guidance in general. First of all, these articles will show the differences between v3.0 and v3.1 from a user perspective: OpenAPI official release notes OpenAPI Blog: Migrating from 3.0 to 3.1 Nordic APIs Blog: What's New in OpenAPI v3.1.0