Mike Kistler mikekistler

There are conventions in REST APIs that help users(developers) quickly understand how the resource works. This is the fundamental concept of REST.

Start with the resources

A REST API provides operations on resources and resource collections.

It should be readily apparent from just looking the paths in the REST API what the resources are.

Restler + Test Recording Proxy

This gist will describe how to run Restler with the Test Recording Proxy to capture service traffic that that later be validated by the Swagger Accuracy tooling.

We'll use the Azure App Configuration service in this example but the concepts should generalize to any Azure service.

Clone and build Restler

git clone https://github.com/microsoft/restler-fuzzer.git

This gist will show how to extract information from the RESTler speccov.json to get a quick view of what operations succeeded and failed in a RESTler run and why.

The primary tool for this is jq.

Here I will use the results of a RESTler test I ran on the Azure DataBricks service.

The test summary reported at the end of the run was:

Restler on Databricks (control plane)

This gist will describe how I ran Restler on the Azure Databricks control plane service and the results I obtained.

Clone and build Restler

git clone https://github.com/microsoft/restler-fuzzer.git
restler_bin=~/bin/restler
mkdir -p $restler_bin
# Need --python because it can’t find “python” — I use an alias that it did not understand.

This file describes a proposal for a new design of "links" support for OpenAPI v4 (Moonwalk)

Problems to be solved

There are three key problems with the OpenAPI v3 support for links that this proposal hopes to address:

No support for linking from a full URL

There are some occasions where a response header or body parameter contains a complete URL, e.g. the "Location"

Resources / relationships for Microsoft DevBox

erDiagram
    Project { 
        string name
    }
    
    Catalog {
 string name

Proposal for new Breaking Change Labels

Update of proposal from this comment.

Breaking Changes

BreakingChangeReviewRequired

Added by automation when it detects a breaking change from a previous GA API version
Blocks merge until a "BreakingChange-Approved*" label is applied

The PR pipeline checks every PR to determine if it (potentially) introduces breaking changes or violates Azure Versioning policy.

The main tool for this is "openapi-diff" which checks two versions of an OpenAPI doc (old and new) and identifies all the "substantive changes" (changes in descriptions and such are ignored).

Our versioning policy requires that any "substantive change" be done in a new API version.

A subset of the "substantive changes" are also considered a "breaking change"

We add labels to the PR as follows:

IF any change is classified as breaking AND the "old" OpenAPI doc is GA (same or different than new API version)

	import { createTypeSpecLibrary } from "@typespec/compiler";
	import { createRule, getLinter } from "@typespec/lint";
	import { isQueryParam } from "@typespec/http";

	export const myLibrary = createTypeSpecLibrary({
	name: "myLibrary",
	diagnostics: {
	"version-policy": {
	severity: "error",
	messages: {

	string Train(AnomalyDetectorClient client, string dataSource, DateTimeOffset startTime, DateTimeOffset endTime, int maxTryout = 500)
	{
	var modelInfo = new ModelInfo(
	dataSource,
	startTime,
	endTime);

	AnomalyDetectionModel model = client.TrainMultivariateModel(modelInfo);
	var modelId = model.ModelId;