The WebAPI in detail

The wwwopac.ashx is not a CGI extension like the older wwwopac.exe, it is a stateful .NET 2.0 http handler (uses IIS), and therefore it doesn’t need to be initialized again for every new query. The wwwopac.ashx is loaded into memory only once, as opposed to the wwwopac.exe, which is reloaded at each individual query. The advantage is obvious: faster response times. The downside is that the adlibweb.xml configuration file and database info files are only loaded at application startup time. If you make modifications in your database .inf files then you will need to restart your application (for instance by recycling the application pool in which wwwopac.ashx runs.
A Collections search statement is converted by wwwopac.ashx to a single sql query, while wwwopac.exe would convert it to multiple sql statements. Moreover, the wwwopac.ashx interfaces directly with SQL Server using these sql queries, and executes combined searches completely on the server, rather than combining partial searches on the client; this speeds up searching drastically. Also, all dataset checks and security checks are performed server side.
With this WebAPI component there’s also no chance of memory leakage or resource leakage, because every instance of wwwopac is disposed of after use.

In the adlibweb.xml configuration file only three levels remain (a global one, a group and database level), and most settings are valid on all levels; further, in the names of the XML tags, camel notation is now consistently used, although pre-existing XML tags are still accepted in their original lower casing so that compatibility with the adlibweb.xml for the old wwwopac.exe is ensured. Click here for an example.

The wwwopac.ashx offers access to more services, namely a data query service via the Collections (advanced) search language, the possibility to retrieve a list of saved searches (aka pointer files), the option to write, remove or update records, to read, write or delete saved searches, the possibility to retrieve metadata from Collections .inf files, functionality for image processing and data validation.

Additional possibilities of Axiell Collections SQL databases allow for more search options – this means that wwwopac.ashx can only be applied to this type of database (Microsoft SQL Server). One addition is the option to search remote indexes via linked fields, even nested if desired. You can also search phonetically and use left, right or middle truncation. See further on in this documentation for a full overview.
The old wwwopac.exe parameters FLDx, OPRx, VALx, TRCx and BOOLx are no longer supported, and neither is dontkeepaspectratio. Use the search parameter instead, with a full Collections advanced search statement. The advanced search statement is much more powerful than the old parameters. It is the responsibility of the user interface code to compose the advanced search statement.

The wwwopac.ashx offers more image handling functionality* than wwwopac.exe. This functionality also improves the performance of Axiell Collections in relation to image processing, especially for the retrieving and scaling of images for display in the Collections Media Viewer or for thumbnail display in the Result set view of a search result. The improved performance is accomplished by not resizing the images to be retrieved for every request, but by reducing or enlarging the image only when first requested, and then saving the result in a cache folder so that for a following identical request a ready-made resized image can be retrieved. So the use of wwwopac.ashx for retrieving images is most useful if the images to which you link in your (museum) media records are pretty large files. For use in thumbnail displays, the image handler already scales those images on the server or retrieves earlier created thumbnails, which results in less data traffic on your network, it lightens the workload of Axiell Collections and also diminishes memory usage of the work station enormously.
You can also use this functionality to directly and safely store images linked to in a media record, in an Axiell Collections SQL database.
A third advantage is that you can hide the path to linked images from users who are only allowed to view records: only the name of the image could still be visible.
The wwwopac.ashx is not a standard part of an Axiell Collections system and won’t be installed automatically. However, the software can indeed become the basis of your own web application, if that application runs on an Axiell Collections SQL database (although images may still be stored in the file system). When using wwwopac.ashx, you are of course free to decide whether or not to apply the image handling possibilities.
* Note that during the development phase of this functionality, there was talk of separate software named Image Handler which could have been used alongside wwwopac; however, the relevant functionality is now only available as part of wwwopac.ashx.

These interface styles include: REST (send a URL and receive XML), DLL (managed C# and VB).

Below schema illustrates the possibilities in the anatomy of a (web) application implementing the Axiell WebAPI.