mikekistler

The Cadl named union:

model Cat {
  meow: int32;
};
model Dog {
  bark: string;
};
union Pet { cat: Cat, dot: Dog }

mikekistler

    string newProjectName = "MyProject";
    RequestContent creationRequestContent = RequestContent.Create(
        new {
            description = "This is the description for a test project",
            language = "en",
            multilingualResource = false,
            settings = new {
                defaultAnswer = "No answer found for your question."
                }
            }

mikekistler

An Alternative Solution for Request/Response Metadata

This gist offers an alternative to Brian's proposal for handling metadata / solving Issue #182.

This proposal is to (mostly) "leave things as is", document them clearly, and then give users guidance for handling cases such as the scenarious identified in the on how to handle cases such as the use cases described in the Wiki page for this issue.

What do I mean by "leave things as is"?

mikekistler

How to Create the Restler Config for an Azure Service

Let me start with the tip that Marina gave me in email:

My usual way of creating config.json is to compile one spec via “--api_spec”, then copying the generated config out of the ‘Compile’ folder and modifying the paths.

There are two different ways to run the Compile step of Restler:

restler compile --api_spec <path to OpenAPI definition>

mikekistler

Advanced use of Restler for an Azure Service

This gist will describe a more advanced use of Restler for the Azure App Configuration service. The goal of this effort is to identify ways to improve coverage.

This scenario reuses some of the machinery described in How to create Restler config.

Clone and build Restler

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

mikekistler

The thought occurred to me today to recast the Azure SDK Design Principles into a corresponding set of design principles for Azure REST APIs. This only took about 5 minutes and I think could be a nice complement to our REST API Guidelines. What do you think?

Azure REST API Design Principles

Azure REST APIs should be designed to enhance the productivity of developers connecting to Azure services. Other qualities (such as completeness, extensibility, and performance) are important but secondary. Productivity is achieved by adhering to the principles described below:

Idiomatic

• The REST API should follow the general design guidelines and conventions for HTTP REST APIs. It should feel natural to a developer familiar with REST.
• We embrace the ecosystem with its strengths and its flaws.

mikekistler

Element Ordering for ApiView Swagger view

This document will define a deterministic ordering of fields at every level of an OpenAPI v2 document. ApiView should transform an input document to conform to this ordering.

ref: OpenAPI v2 Specification

Top level

ref: Swagger Object

mikekistler

Running RESTler on the Azure Keyvault service

Create an initial config

Invoke RESTler generate_config, passing a list of the REST API defintion files. This will create a RESTler config file with these files in the SwaggerSpecFilePath.

specs=$(find /Users/mikekistler/Projects/Azure/azure-rest-api-specs/specification/keyvault/resource-manager/Microsoft.KeyVault/stable/2022-07-01 -type f -depth 1)
dotnet $restler_bin/restler/Restler.dll generate_config --specs ${=specs}

mikekistler

Here is a collection of entity-relationship diagrams I created for the Azure Load Test service based on the Key Concepts in the public documentation.

Test

erDiagram
    TEST { 

mikekistler

Here is a collection of entity-relationship diagrams for the Azure Load Test service based on just the path structure in the REST API.

Load Test

erDiagram
    LOAD-TEST { 
        string testId
 }