gistfile1.txt

[[ch_the_application]]
== The Application ==
Up to this point we have discussed the tools that you can use to build Web APIs.  We have discussed the fundamentals of the HTTP protocol, the basics of using _ASP.NET Web API_ and how the architectural pieces fit together.  This is essential knowledge, but not the primary objective of this book. This book is about how to build _evolvable_ Web APIs.  This chapter is the where we begin to talk about how to create a Web API that can evolve over period of years.  A long enough period of time that business concerns will change and technology will change.

Rather than discuss the issues in abstract scenarios, we decided that we must walk the walk and build an API that demonstrates the concepts we wish to convey.  This API will concern a domain that should be familar to every developer and we believe is sufficiently realistic that it could be adpoted in real world scenarios. 

Before delving into the details of the domain, we will ensure that evolvability is something we are truely prepared to pay for.  It does not come for free.  In order to achieve evolvability, where appropriate, we will apply the constraints of the REST architectural style.  It is critical to recognize that we are not attempting to create a "RESTful API".  REST is not the objective, but a means to an end.  Evolvability is the goal.

Before we can begin to design our Web API, we need to define the building blocks for our application domain.  This is part of the process that is so often ignored when people attempt to build distributed systems today.  When building a classic browser based application, the soultion architecture is largely already defined.  HTTP, HTML pages, CSS, javascript all form the  components of the final solution.  However, with a Web API, you are no longer constrained by the choices of the web browser. A web browser may be only one of many different client components in the distributed system.

With the building blocks defined, chapter 6 will provide a sample API that assembles these components into a Web API.  These component pieces will be essential knowledge for building a client application in chapter 8.  By defining the reusable components independently to the API, the client can be built with knowledge of how to interact with these components without needing to know the precise shape of the Web API.  Hypermedia will allow the client to discover the shape of the API and adapt to changes as the API evolves.


=== Why evolvable? 

==== Barriers to evolution

==== Why not just version?

=== Application objectives
==== Goals
==== Non goals

=== Issue Tracking Domain

=== Semantic Model

=== Resource Models