Category: HTTP API

Self Descriptive HTTP API in ASP.NET Core: Siren

Derek Comartin 5 Comments

This post is in my Self Descriptive HTTP API in ASP.NET Core series. It demonstrates how to design an HTTP API like a regular HTML website. Bringing the concepts of links and actions to your API allows your clients to consume it with ease.

If you’re new to this series, here are earlier posts to get up to speed:

If you have any questions, please follow me on Twitter.

Follow @CodeOpinion on Twitter

Siren

I mentioned that Siren was one media type that appeals to me because it supports both links and actions.  This is important because I generally build core parts of an application following CQRS by implementing commands that change the state of my system or queries that return state.

Libraries

There are a few projects/libraries that help with generating a output that follows the siren spec.

With all these libraries, the number of downloads on NuGet is really low. However, I think they all have value in at least looking at the source to get some ideas if you aren’t comfortable with taking a dependency on them.

Nancy.Siren

I discovered Jonathan Channon’s Nancy.Siren a couple months ago and really liked the idea of having your endpoints return your usual DTO and having a response processor mutate your DTO into a Siren payload.

If you use Nancy (as I do) this is worth looking at.  I plan on digging into this a bit more for all you NancyFX fans.

Migrap.AspNetCore.Hateoas

This is a project I found on GitHub that takes the same approach as Nancy.Siren by handling requests that accept application/vnd.siren+json by transforming them to a siren payload.

I’ve forked this and have added a ASP.NET Core MVC application to it to build a Todo demo.

All the source code you will find below through the rest of this post is available on GitHub.

Note: I’m intentionally leaving some snippets of setup code out of this blog post.  The demo source code in its entirety is pretty easy to follow.

Todo

So for some context about this Todo application.  I’ve got a simple model to represent a todo item.

I’ve setup a simple Controller that provides endpoints for performing the following:

  • Get all the Todo’s
  • Get an individual Todo
  • Add a Todo
  • Delete a Todo
  • Mark a Todo as complete

This should look at pretty familiar and straight forward.  Here’s a result in postman when getting the list of our Todo’s.

 

Relation and Actions

What’s missing from that payload are the related URIs or actions I could perform related to this resource or others.  As mentioned in my prior blog post about Hypermedia, is that where media types like Siren provide the ability to give your consuming clients this information.

StateConverter

In order to transform our collection of TodoModel’s into a siren payload we need to create an implementation of the IStateConverter.  We will return a Document that will describe the properties and entities (Todo’s) for this resource.  For each Todo we will also provide the URI of how to access it specifically.

 

Once we do this, if we make our HTTP call but this time specifying an Accept header of application/vnd.siren+json, we will get our siren payload.

 

Next

All the source code for my demo is available on GitHub.

In the next few posts we will start digging in more by adding actions and workflow based on application state.

If anyone has any other suggestions or recommendations about this series, please leave comment or let me know on twitter.

  1. Building a Self Descriptive HTTP API in ASP.NET Core
  2. Object as Resource
  3. Hypermedia
  4. Siren
  5. HATEOAS
  6. Hypermedia Clients
Follow @CodeOpinion on Twitter

Self Descriptive HTTP API in ASP.NET Core: Object as Resource

Derek Comartin Leave a comment

In my opening post I went over some of the issues I encountered when initially developing an HTTP API.  In this post I’m going to cover some of those pain points and what I think the solution was.

Objects

The first pain point revolves around the idea of your HTTP API returning objects.  Meaning you serialize an object to JSON and return to the client.

This seems pretty typical.   Almost every example you find in regards to Web API describes this behavior.

Here’s an example of what this looks like:

We’re doing nothing more than fetching a record out of our repository/database and serializing it down the to the client.

On the flip side, all of our endpoints for mutating state of our system take the same object back.

Object as Resource

There was a great and short blog post by Alex Moore last year.

You’ve doubtless seen the OAR pattern out in the wild. I’d define its constraints this way: 1. a resource maps 1:1(-ish) to an object in your server’s application logic, 2. uris and http methods are given conventions mapping to CRUD operations

These are what most examples I find describe.  If you ever used OData with Entity Framework, it’s another great example of OAR.

Model Changes

The first obvious issue with this is your exposing your internal data structure to your consuming clients.

If you do not have ownership over the clients, then making any breaking change to the structure TodoItem is going to be pretty difficult.

This is really problematic when your internal models are still evolving.

DTO

The obvious answer is to create DTO (Data Transfer Objects) as the essentially a contract to your consuming clients.  Meaning you will create a separate object that will be serialized and return to clients rather than your database entity.

This is generally a recommended approach that I use.  This is where a library like AutoMapper shines.

Representation

But we need to take this a step further.  The idea of returning serialized DTO that still are in a 1:1-ish with some underlying data entity only provides our clients a single piece of information.

Often times in order for the client to perform a given action, they generally need related data.

An example, maybe our Todo application had the ability to create different categories so we could break up and categorize our items.  If we wanted to edit our TodoItem to specify a Category, we would need to pass it the CategoryId.

How exactly do we get the list of categories from the client?  Would the client be required to call another endpoint to them?

Why not return them in our DTO?

We would be doing this already if you were creating an MVC application returning a rendered HTML to the client/browser.

Your edit screen would contain a <select> list of all the categories in your edit <form>.

Messages

If you start thinking about sending down messages to the client rather than objects, you can open up to the idea of your messages being a much more rich representation.  This representation could contain referential data, actions the client could preform or other places the client could navigate your HTTP API.

Last year, I wrote a blog post about your Resource Model not being your Data Model after I seen a great tweet by Mike Amundsen.

Next

In my next post I’m going to look at how we build HTML web applications and what we can learn and use to develop our HTTP APIs.  If anyone has any other suggestions or recommendations about this series, or the sample project to convert, please leave comment or let me know on twitter.

  1. Building a Self Descriptive HTTP API in ASP.NET Core
  2. Object as Resource
  3. Hypermedia
  4. Siren
  5. HATEOAS
  6. Hypermedia Clients


Building a Self Descriptive HTTP API in ASP.NET Core

Derek Comartin 7 Comments

Self Descriptive HTTP APIWe have all been doing “web services” forever.  My first introduction was in the late 90’s with XML-RPC and WDDX.  Followed up soon after with SOAP.  Good times.  Oh and remember WS-*.  Don’t remind me.

Why?

Over the last couple years, I’ve really taken an interest in HTTP APIs.

I’ve been meaning to post about my experiences developing an HTTP APIs.  It’s been an interesting last couple of years and I think there is quiet a bit to share.

Issues

I can only speak from my experiences and give some of the context about my situations.  Hopefully you can relate and translate it to your own projects and make a determination if what I struggled with is beneficial in your context.

There were four major pain points that I ran into developing our HTTP API and Clients.

  • Unable to change internal data structures that got exposed/serialized to Clients
  • Unable to change endpoint paths/routes
  • Endpoint documentation (incoming and outgoing payloads)
  • Workflow logic living on the client

HTTP APIs

Sometimes all you need is to do CRUD.  Sometimes that’s the last thing you should be doing.

Most examples and getting started tutorials usually demonstrate exposing your database structure and provide GET/POST/PUT/DELETE as away of performing CRUD.

You basically end up with HTTP endpoints that are a 1:1 mapping with a database entities.

This also makes it incredibly hard to change your API.

Go beyond serializing a database row into JSON

I’ve realized that developing an HTTP API is not much different than developing a regular HTML Website.

I started developing my HTTP APIs like I would if I were creating a static HTML or server side rendered HTML web application.  This means bringing the concepts we’ve been using for ages with HTTP and HTML such as links and forms.

(Un)Surprisingly, this lead to several benefits.  First, our API clients could consume our API with ease.  Second, they became dumb.  Workflow or business logic stayed on the server and didn’t leak to the client.

Series

This series of posts is going to cover some misconceptions I had in regards to HTTP APIs and REST.

Producing an HTTP API using Hypermedia and various media types.

Consuming an HTTP API that uses Hypermedia.

How you can use CQRS and Hypermedia together.

Similar to my Fat Controller CQRS Diet series, I’m going to convert an existing web application.   Currently I’m thinking of using the MVC Music Store again.  If anyone has any other suggestions or recommendations about this series, or the sample project to convert, please leave comment or let me know on twitter.

  1. Building a Self Descriptive HTTP API in ASP.NET Core
  2. Object as Resource
  3. Hypermedia
  4. Siren
  5. HATEOAS
  6. Hypermedia Clients