The core mechanism used to serve web applications based on Active Web Element is the GenerateHTTPResponse function. GenerateHTTPResponse takes two arguments: the first is the expression being served, while the second is a representation of the HTTP request. It returns an HTTPResponse object that is then passed to the servlet infrastructure in order to be served to the client.

GenerateHTTPResponse can be used to simulate and debug the behavior of the web application under development.

A typical definition of GenerateHTTPResponse is recursive; for example, the definition for APIFunction contains the logic required to validate the query parameters, but once the body of the APIFunction is evaluated, the result is passed through GenerateHTTPResponse again. This approach is somewhat similar to how typesetting in Wolfram Language works, and it allows for great flexibility because Active Web Element expressions can be nested to achieve more complex behavior.

A classic example of nesting is URLDispatcher, which acts as a URL router, defined as a list of rules that have various Active Web Elements on the right-hand side.

Debugging Using GenerateHTTPResponse

GenerateHTTPResponse can be used to debug the deployment code interactively in a notebook. Let us suppose that the expression at an endpoint is given by:

We can now simulate the behavior of this endpoint by invoking GenerateHTTPResponse with an appropriate second argument:

It is clear that something is not quite right. You will need to transform the string "n" into a number; otherwise, IntegerDigits will not evaluate:

Retest:

Other advantages of this style of debugging are the ability to see messages, which is complicated by the need to go through ResponseForm on the web, and the ability to attach the Wolfram Language debugger, which is impossible on the web.

Adding Definitions to GenerateHTTPResponse

GenerateHTTPResponse functionality can be extended to other symbols by using UpValues. This can prove to be practical in cases where one wants to permanently change defaults or wants to add new functionality. In this section, both things will be shown.

Suppose one is building a web application composed of more than one APIFunction, but the default method of communication with the rest of the web application is XML rather than JSON. In order to avoid writing APIFunction[…,{"XML",None,"XML"}] for every APIFunction, one can write the following code in the init.m that gets loaded by the Wolfram kernels in the Wolfram Web Engine:

Note that in the above, only the one-argument version of GenerateHTTPResponse is defined, because the servlet will automatically take care of blocking $HTTPRequest, and HTTPRequestData will be automatically populated.

Additionally, if one is using the ServiceDeploy interface to build the web application, the following definition is necessary in the deployer kernel:

Now suppose one is trying to define a web application for FittedModel:

The behavior of this application on the server can now be simulated: