This is the second post in a series about REST, where I intend to debunk some commonly repeated mistakes and bad advice for practitioners of RESTful services. The central, and agreeably most important element of any API, is the resource. On the Web resources are identified and addressed by URLs. REST defines some clear rules about these identifiers, yet we so commonly break them. Let’s see how this happens and what are the consequences.

This is the first in a series of posts where I want to discuss misconceptions about the REST architectural style. Much has been written and told about REST, yet there are a number of common mistakes prevalent in the community. In this post I will introduce (again) the basics of REST as defined by Roy T. Fielding.

I the process of preparing my talk at Boiling Frogs conference in Wrocław I’ve been reading a lot about REST and Hypermedia APIs. Just today I came across two interesting blog posts by Arnaud Lauret aka API handyman, who proposes a Hypermedia API Maturity Model (HAMM). A concept similar to the Richardson Maturity Model, but applicable only to Level 3 REST APIs. I’d like to share my thoughts on some of the proposal.

I’ve been looking for a way to create a collection component, in which I would declare the collection item template in the Light DOM and then render that template bound to each item. I’m using Polymer, because it is fun and insanely productive tool for creating Web Components. When I was already close to actually writing my component in pure Web Component API I discovered the Templatizer bevahiour.

For a long time now W3C has been working on Web Components, the groundbreaking specification, which will dramatically change the way web applications are created. Google’s own Eric Bidelman calls it a Tectonic Shift and for good reason.

Lately I have been considering employing Web Components in my ever-upcoming hobby project. The missing piece I haven’t found in modern web app frameworks is UI based on application state (think REST). Typically the UI displayed to the use is tied to the route - or address, which is potentially brittle and not ideal for a truly hypermedia-driven application.

Two months ago, at the Wrocław .NET User Group, Luca Bolognese talked about Literate Programming.

For those who don’t know, Luca Bolognese is best known for being the father of Microsoft’s functional language F#. He currently works for Credit Suisse - the Swiss-American investment bank where he implements uber-geek algorithms for counting a lot of money :).

A long time ago, back in 2011, I have implemented the R2RML using dotNetRDF.

R2RML is a specification, which defines how to map SQL databases to RDF triples. This way it is possible to publish existing data from relational databases as Linked Data to give one example

I myself have always struggled with proper versioning of .NET software. I’m not alone:

• Best practices/guidance for maintaining assembly version numbers
• What are differences between AssemblyVersion, AssemblyFileVersion and AssemblyInformationalVersion?

A linked issue, which adds to the complexity is mixing .NET versioning with NuGet SemVer guidelines. This has been described for example in this blog post

REST

Representational state transfer or REST defines a number of architectural constraints, which when applied allow building software, which is fast, scalable and simply interacted with.

TL;DR; RESTful application works very much like the Internet. A client requests a known resource by its identifier and follows links included in the representations to move to another state. No further information should be required by the client to know except the initial identifier.