In a world dominated by APIs, where everyone seems to implement microservices with so many paradigms and stadards to choose from, REST seems to be the default option.

Despite that, many of these so-called REST APIs have a littele to do with what REST should be, and are often brittle because we ignore some of the most powerful constraints.

We ignore HATEOAS, under the pretext that will add a performance penalty, or because we don't see the imediate benefit from it. When it comes to versioning, we prefer to
version by having the version in the URL path, and sometimes we never change the version.

We are pressured to deliver, to meet the deadlines
and this leads sometimes to poor desing. We choose a few HTTP Verbs and status codes that are all purpose, and that's it.
In reality, REST is not only about verbs and namings, is also about meaning, empaty towards our API consumers, longevity
and leveraging everything that the underlying protocol has to offer.

In this session we will look over how we can design a REST API that is flexible and evolvable by being in sync with what
HTTP has to offer.
We will look over OData as a way to filter data, versioning, hypermedia types specs and status codes by fine-tuning .NET Core.