As you might already know, a Native Web App following the Single-Page Application approach will roughly handle the client-server communication in the following way:

In our specific scenario, the index.html role is covered by the /Views/Index.cshtml view file that is returned by the Index action method within the HomeController; however, the base concept is still the same.

In case you're wondering about what these Async Data Requests actually are, the answer is simple--everything, as long as it needs to retrieve data from the server, which is something that most of the common user interactions will normally do, including (yet not limited to) pressing a button to show more data or to edit/delete something, following a link to another action view, submitting a form, and so on. That is, unless the task is so trivial--or it involves a minimal amount of data--that the client can entirely handle it, which means that it already has everything it needs. Examples of such tasks are show/hide element toggles, in-page navigation elements (such as internal anchors), and any temporary job requiring to click on a confirmation or save button to be pressed before being actually processed.

The preceding picture shows, in a nutshell, what we will do; define and implement a pattern to serve these JSON-based, server-side responses our application will need to handle the upcoming requests. Since we've chosen to develop an application featuring a strongly data-driven application pattern, we'll surely need to put together a bunch of common CRUD-based requests revolving around a defined set of objects that will represent our various entries.

If we consider the master plan we put down in Chapter 1, Getting Ready, we can already define most of the entries we will need. We'll definitely have Quizzes, which will be the main entities of our application; they will contain one or more Questions, each one with a list of Answers, and a number of possible Results. Eventually, we'll most likely add Users to the loop, so we'll be able to implement an authentication/authorization mechanism that will be used by our application to determine who can view/edit/delete what.

For each one of them, we'll develop a set of requests that will address some common tasks such as display a list of entries of the same type, view/edit an entry's data, and delete an entry.

Before moving ahead, let's take a more detailed look at what happens between any of these Data Requests issued by the client and JSON Responses sent out by the server, that is, what's usually called the Request/Response flow:

As we can see, in order to respond to any client-issued Data Request, we need to set up a server-side Controller featuring the following capabilities:

• Read and/or write data using the Data Access Layer
• Organize these data in a suitable, JSON-serializable ViewModel
• Serialize the ViewModel and send it to the client as a Response

Based on these points, we can easily conclude that the ViewModel is the key item here. That's not always correct, it could or couldn't be the case, depending on the project we're building. To better clarify that, before going ahead, we should definitely spend a couple of words on the ViewModel object itself.