Application contracts with Swagger powered APIs for .NET or Why SwaggerProvider

This post is part of the F# Advent Calendar in English 2015 project.
And special thank you to Phillip Trelford for the idea of F# Advent in English year ago.

In this post I want to talk about how we design software, what we should care about and what we should not.

The story of The Contract

The initial thing is a problem. Nobody writes code without understanding what he/she is doing and what he/she expects to receive at the end. The task (problem description) may come from anywhere: it may be task from your boss or an awesome idea that pretty soon can change the world and bring you a lot of money or some tool / OSS project that will make your life easier in the future.

When you have a clear problem definition, you can start thinking about the solution. There are plenty of ways to solve any problem. You can choose any programming language, any operating system, any programming paradigm, any framework, any tool-set and so on. In order to choose one (the best in your case) solution you start applying real world constraints to reduce the number of solutions. You will probably decide to use a language and tools, which you are more familiar with or which suits better for this particular task. People do this because we all have very important real-life constraint – it is the time. Time-to-market is always important. Nobody starts writing a new operating system just because he/she can do it. We always try to minimize amount of work that should be done to speed up time-to-market.

When you actually start hacking, the thing you start with is `architecture`. Argh, I said that arch.. word. But architecture is nothing more than decomposition. If you do it right in terms of your constraints and limitations – you are almost done. After that, you should write code for small pieces and compose them to get the solution. But what defines the right decomposition? The answer is contracts!

Sounds really simple, does not it? However, it is not so far from the truth. Real-world solution architecture is always state of art, it cannot be super cool for all things, but it can fit your requirements to certain extent. All you can do mastering the architecture is to decompose your monolith idea to simple manageable components with clear responsibilities and clear contract.

The implementation of contract in programming language level is an interface (the promise of capabilities to the world). The implementation of interfaces in F#/C# is pretty good. You as a developer should only define an interface and implement it somewhere to provide a capability by contract. When you are on the other side and want to consume provided capabilities you should only reference component that defines contract and use it with almost zero overhead.

Based on the experience with interfaces, you have three ways of interaction with contract:

  1. Design (define) contract
  2. Provide (implement) contract
  3. Consume contract

But it is not so simple, when your application is larger than one executable file… What happens when you cross process and/or machine boundaries? In this case, we need a technology that allows us to setup the component that provides contract to one machine and consumes this contract on another machine with the same elegance as interfaces do this. At this moment, higher-level contracts (so called API) come to play.

There are plenty of technologies that can help you to develop some sort of API for your component. Probably first helpful thing that comes to mind is WSDL (Web Service Definition Language). When you choose WSDL as your contract language you receive plenty of tools that help you to manage your API, generate implementation from API contract, generate contract from your implementation, generate code that encapsulate all communication difficulties for consumers and so on. WSDL world is pretty mature and beautiful (I really love it), but it usually comes with SOAP and communication protocol that does not suitable for all types of cross-machine communication.

There are some real-world cases when you need more lightweight and fast communication mechanism that can be “easily” consumed from different languages and run-times. In such cases, people more often decide to provide RESTful APIs. BUT, all of you who design RESTful API for your systems and components SHOULD REMEMBER that technology that you use to design and implement contract SHOULD also provide a way to CONSUME your API. It is your responsibility to care about consumers, they should be focused on solving their own task using your API rather than writing boilerplate code to consume your API.

Swagger

One of technologies that provide such goodness for developers is Swaggernlp-logo-navbar

Swagger is a simple yet powerful representation of your RESTful API. With the largest ecosystem of API tooling on the planet, thousands of developers are supporting Swagger in almost every modern programming language and deployment environment. With a Swagger-enabled API, you get interactive documentation, client SDK generation and discoverability.

Swagger Specification is able to describe pretty wide range of RESTful APIs. Swagger comes along with Swagger Edit that allows contract first API development. APIs that have Swagger schema can easily be integrated with Swagger UI – very powerful interface that dramatically simplify studying of new API (demo). Swagger ecosystem also has tools that generate client code for wide list of languages.

In the .NET world, exists a project called Swashbuckle, which generates Swagger schema to ASP.NET WebAPI services and plugs Swagger UI in your application. I’ve already blogged about how to use Swashbuckle from F# Web Apps.

Swagger is used in ASP.NET API app in Azure App Service and may come to Nancy very soon as well.

F# Swagger Provider

swaggerAs you may already understand, Swagger ecosystem looks very promising in general and Swagger Specification perfectly matches with F# Type Providers approach. So, I am glad to present the SwaggerProvider.

In order to start you need to add reference to SwaggerProvider NuGet package and pass Swagger JSON schema to it (for this example I will use a schema from Petstore – Swagger demo app).

#r "SwaggerProvider/SwaggerProvider.dll"
open SwaggerProvider

type PetStore = SwaggerProvider<"http://petstore.swagger.io/v2/swagger.json">

So, you are generally done. Type Provider parses provided schema and generates all required data types and methods to call API. Note that SwaggerProvider is generative type provider and generates types and methods that exist in run-time, so that means that it can be used from C# code as well.

swagger_defs

swagger_pets

Even if the RESTful API that you need to consume does not gently provide Swagger schema for you, you still can use SwaggerProvider to call it. It should be easier to manually describe schema once than to write and support source code for all REST calls.

Let’s say that we want to call GitHub API to get all fsprojects repositories. For this API call schema will look like this

{
    "swagger": "2.0",
    "info": {
        "description": "This is a Sample for GitHub API.",
        "version": "1.0.0",
        "title": "Swagger GitHub"
    },
    "host": "api.github.com",
    "basePath": "/",
    "tags": [
        {
            "name": "repos",
            "description": "Repositories API"
        }
    ],
    "schemes": [ "https" ],
    "paths": {
        "orgs/{orgId}/repos": {
            "get": {
                "tags": [ "repos" ],
                "summary": "List organization repositories",
                "description": "",
                "operationId": "orgRepos",
                "consumes": [ "application/json" ],
                "produces": [ "application/json" ],
                "parameters": [
                    {
                        "name": "orgId",
                        "in": "path",
                        "description": "Organization name",
                        "required": true,
                        "type": "string"
                    }
                ],
                "responses": {
                    "200": {
                        "description": "successful operation",
                        "schema": {
                            "type": "array",
                            "items": {
                                "$ref": "#/definitions/Repo"
                            }
                        }
                    }
                }
            }
        }
    },
    "definitions": {
        "Repo": {
            "type": "object",
            "properties": {
                "id": {
                    "type": "integer",
                    "format": "int64"
                },
                "name": {
                    "type": "string"
                }
            }
        }
    }
}

If you use Visual Studio to edit Swagger schema, you will be pleasantly surprised by “Intellisense for JSON Schema in the JSON Editor

gh-vs

This JSON describes one data type Repo, that contains simplified version of GitHub Repository data type, and description of one API method /orgs/{orgId}/repos that does the job. Now you are able to use this schema to call GitHub API.

gh_def

gh_repos

But if you really want to make a call to GitHub API, you need to specify real user agent header and SwaggerProvider allows you to do this:

open SwaggerProvider

let [<Literal>] schemaFile = __SOURCE_DIRECTORY__ + "\GitHub.json"
let [<Literal>] headers = "User-Agent=Googlebot/2.1 (+http://www.google.com/bot.html)"
type GitHub = SwaggerProvider< schemaFile, headers >;

let names =
    GitHub.Repos.OrgRepos("fsprojects")
    |> Array.map (fun x -> x.Name)

gh_works

Note: SwaggerProvider does not support schemes in YAML format yet. But this feature is definitely will be implemented, because it dramatically simplifies manual schema creation.

Please share your thoughts about SwaggerProvider and do not be shy to try it and report issues if any.

Special thanks to APIs.guru project for maintenance of wide range of real-world Swagger schemes that were used to test SwaggerProvider.

Simple Web API OWIN host using F#

Very nice starter pack for OWIN Web API with F#. If you use Paket manager you need only one dependency to `Microsoft.AspNet.WebApi.OwinSelfHost` NuGet package

Also Web API can be easily configured to use Swagger UI.

Exception Caught

I thought it would be good to write a simple OWIN Web Api host using F# to show how easy it is to interop between the two languages and as a fun experiment. You can find all of the source code from this blog post at the FSharpWebApi github repository.

If you open the Program.fs solution in the github repository you will see the following two lines of code are reponsible for starting the web server:

The getAppBuilder function is defined in the WebServerBuilder module as follows:

The getAppBuilder function returns a function with the signature (IAppBuilder) -> (). This signature is the same as the one expected by the first parameter of WebApp.Start. The reason for breaking this function off into its own module is so that it can be tested.

The cool thing about the Web Api Owin Self host stack is that there is a nuget…

View original post 491 more words

Swagger for F# Web Apps

nlp-logo-navbarSwagger is a simple yet powerful representation of your RESTful API. With the largest ecosystem of API tooling on the planet, thousands of developers are supporting Swagger in almost every modern programming language and deployment environment. With a Swagger-enabled API, you get interactive documentation, client SDK generation and discoverability.

Swagger is very powerful framework that is able to generate schema and rich UI for your RESTful API. As I know, Swagger is very popular framework especially in the non-.NET world. You probably have already seen Swagger UI (like this) at several resources.

It turns out that it is not hard to use Swagger for .NET F# apps. There is a project called Swashbuckle, which adds Swagger to WebApi projects.

First of all, you need to create F# ASP.NET Web API project. You can do it using “F# Web Application templates (MVC 5 and Web API 2.2) by Ryan Riley and Daniel Mohl“. Choose “Web API 2.2 and Katana 3.0” option in project creation wizard.

So, now you have F# Web App with RESTful API: CarsController with two services ‘/api/cars‘ and ‘/api/car/{id}‘. Everything is awesome but we do not have UI that is able to show a list of available services, their parameters and return types. Swashbuckle will help us here, we need to install ‘Swashbuckle.Core‘ package to our web app.

Install-Package Swashbuckle.Core

The last step is to update HttpConfiguration in Startup.fs in proper way to register Swagger. Add following three lines to the end of RegisterWebApi method.

open Swashbuckle.Application

type Startup() =
    static member RegisterWebApi(config: HttpConfiguration) =
        // ...
        // Swagger configuration
        config
          .EnableSwagger(fun c -> c.SingleApiVersion("v1", "My API") |> ignore)
          .EnableSwaggerUi();

That’s all! When you start your web application and open ‘/swagger/ui/index‘ URI you will see beautiful documentation for your RESTful API.
SwaggerUI

Lightweight websites with F#

The Cockney Coder

There are several common approaches I’ve seen people take on the .NET platform when writing web-based applications that I want to review in terms of language and framework choice: –

  • Adopt a conventional MVC application approach. Write static HTML that is emitted from the server using e.g. Razor markup + C# / VB .NET, write your controllers and any back-end logic in C#.
  • As above, but replace your back-end logic with F#. This is a reasonable first step to take, because essentially all your data access “back-end” processing are performed in a language that it’s best suited for, whilst your C# is relegated to essentially thin controllers and some simple markup logic.
  • Adopt a “SPA”-style approach. But this I mean split your web application into two distinct applications – a client-side application that is self-managing, typically using Javascript and some framework like Knockout or AngularJS; meanwhile your back-end is a…

View original post 1,115 more words

Declarative authorization in REST services in SharePoint with F# and ServiceStack

This post is a short overview of my talk at Belarus SharePoint User Group at 2013/06/27.

The primary goals were to find an efficient declarative way to specify authorization on REST service (that knows about SharePoint built in security model) and try F# in SharePoint on a real-life problem. Service Stack was selected over ASP.NET Web API because I wanted to find a solution that operates in SharePoint 2010 on .NET 3.5. Continue reading “Declarative authorization in REST services in SharePoint with F# and ServiceStack”

ServiceStack: F# Client Application

In the previous post “ServiceStack: New API – F# Sample (Web Service out of a web server)” we implemented a self-hosted service with ServiceStack. That service has multiple out-of-the-box endpoints, including a REST one.

The next interesting question is “How to call this service?”(preferably in a strongly-typed way). The answer is simple, ServiceStack team have already made ​​this for us.  We can reuse types that designed for server-side code to make client code prettier. ServiceStack provides a list of different service clients for client applications.

open System
open ServiceStack.ServiceHost
open ServiceStack.ServiceClient.Web

[<CLIMutable>]
type HelloResponse = { Result:string }

[<Route("/hello")>]
[<Route("/hello/{Name}")>]
type Hello() =
    interface IReturn<HelloResponse>
    member val Name = "" with get, set

let baseUri = "http://localhost:8080/"

// Option 1 : Json call
let jsonCall() =
    let client = new JsonServiceClient(baseUri)
    client.Post(Hello(Name="json"))

// Option 2 : Xml call
let xmlCall() =
    let client = new XmlServiceClient(baseUri)
    client.Post(Hello(Name="xml"))

// Option 3: Jsv call
let jsvCall() =
    let client = new JsvServiceClient(baseUri)
    client.Post(Hello(Name="jsv"))

[<EntryPoint>]
let main args =
    printfn "Json call : %A" (jsonCall())
    printfn "Xml call : %A" (xmlCall())
    printfn "Jsv call : %A" (jsvCall())
    Console.ReadLine() |> ignore
    0

ServiceStack: New API – F# Sample (Web Service out of a web server)

Two weeks ago in F# Weekle #6 2013 I mentioned Don Syme’s “F# + ServiceStack – F# Web Services on any platform in and out of a web server” post. There were two samples of  using ServiceStack from F#. One of these examples is given on ServiceStack wiki page in Self Hosting section. It is also detailed in Demis Bellot’s “F# Web Services on any platform in and out of a web server!” post.

Unfortunately, this example is already obsolete. Some time ago, ServiceStack released a brand new API that significantly changed programming approach, especially routing (for details see “ServiceStack’s new API design“). But I am happy to say that you can find an updated example below!

New design is more typed. In the previous version IService‘s methods returned the Object, but now Service returns concrete type that is defined by IReturn<T> interface of request message.

open System
open ServiceStack.ServiceHost
open ServiceStack.WebHost.Endpoints
open ServiceStack.ServiceInterface

[<CLIMutable>]
type HelloResponse = { Result:string }

[<Route("/hello")>]
[<Route("/hello/{Name}")>]
type Hello() =
    interface IReturn<HelloResponse>
    member val Name = "" with get, set

type HelloService() =
    inherit Service()
    member this.Any (request:Hello) =
        {Result = "Hello," + request.Name}

//Define the Web Services AppHost
type AppHost() =
    inherit AppHostHttpListenerBase("Hello F# Services", typeof<HelloService>.Assembly)
    override this.Configure container = ignore()

//Run it!
[<EntryPoint>]
let main args =
    let host = if args.Length = 0 then "http://*:8080/" else args.[0]
    printfn "listening on %s ..." host
    let appHost = new AppHost()
    appHost.Init()
    appHost.Start host
    Console.ReadLine() |> ignore
    0

For comparison, the previous version is:

open System
open ServiceStack.ServiceHost
open ServiceStack.WebHost.Endpoints

type Hello = { mutable Name: string; }
type HelloResponse = { mutable Result: string; }
type HelloService() =
    interface IService with
        member this.Any (req:Hello) = { Result = "Hello, " + req.Name }

//Define the Web Services AppHost
type AppHost =
    inherit AppHostHttpListenerBase
    new() = { inherit AppHostHttpListenerBase("Hello F# Services", typeof<HelloService>.Assembly) }
    override this.Configure container =
        base.Routes
            .Add<Hello>("/hello")
            .Add<Hello>("/hello/{Name}") |> ignore

//Run it!
[<EntryPoint>]
let main args =
    let host = if args.Length = 0 then "http://*:1337/" else args.[0]
    printfn "listening on %s ..." host
    let appHost = new AppHost()
    appHost.Init()
    appHost.Start host
    Console.ReadLine() |> ignore
    0

Update: An example of ServiceStack New API for F# 2.0 users. F# 2.0 does not have val keyword / auto-properties which were used in the first example.

</pre>
open System
open ServiceStack.ServiceHost
open ServiceStack.WebHost.Endpoints
open ServiceStack.ServiceInterface

type Project() =
    let mutable projectID = 0
    let mutable projectName = ""
    let mutable companyName = ""
    let mutable projectStatus = ""
    member this.ProjectID with get() = projectID and set(pid) = projectID <-pid
    member this.ProjectName with get() = projectName and set(pn) = projectName <- pn
    member this.CompanyName with get() = companyName and set(cn) = companyName <- cn
    member this.ProjectStatus with get() = projectStatus and set(ps) = projectStatus <-ps

type ProjectResponse() =
    let mutable projects = List.empty<Project>
    member this.Projects with get() = projects and set(pr) = projects <- pr

[<Route("/Project/{ProjectName}")>]
type ProjectRequest() =
    let mutable projectName = ""
    interface IReturn<ProjectResponse>
    member this.ProjectName with get() = projectName and set(n) = projectName <- n

type ProjectService() =
    inherit Service()
    member this.Any (request:ProjectRequest) =
        ProjectResponse(
             Projects = [Project(ProjectName=request.ProjectName, ProjectID=1, CompanyName="A")])

//Define the Web Services AppHost
type AppHost() =
    inherit AppHostHttpListenerBase("Project F# Services", typeof<ProjectService>.Assembly)
    override this.Configure container = ignore()

//Run it!
[<EntryPoint>]
let main args =
    let host = if args.Length = 0 then "http://*:8080/" else args.[0]
    printfn "listening on %s ..." host
    let appHost = new AppHost()
    appHost.Init()
    appHost.Start host
    Console.ReadLine() |> ignore
    0
<pre>