The AutoQuery support in ServiceStack adds Auto Querying functionality akin to OData’s querying support for Web Api, although we’ve strongly disregarded their approach which we’ve long considered promotes web service anti-patterns. To explain the design goals behind AutoQuery it’s important to identify and avoid the parts of OData we consider make it a poor fit for services.
Why not OData goes through what aspects make OData a poor Services technology who’s Services anti-patterns violates Microsoft’s own Services Design guidelines where its implementation, complexity, poor performance, tight-coupling and inhibitive versionability is reminiscent of their earlier rigid, heavy-weight SOAP/SOA frameworks that’s still entrenched in a number of legacy systems - poorly ideologised, over-engineered Services technology many companies are still trying to recover from.
The solution to overcome most of OData issues is ultimately quite simple: enhance the ideal API the developer would naturally write and complete their implementation for them! This is essentially the philosophy behind AutoQuery which utilizes conventions to automate creation of intent-based self-descriptive APIs that are able to specify configurable conventions and leverage extensibility options to maximize the utility of AutoQuery services.
AutoQuerying aims to work like optional typing by making it easy to expose contract-less data services for rapid prototyping, then allowing the API to be gradually formalized by decorating Request DTO’s with its supported usage, whilst allowing complete freedom in either utilizing and extending AutoQuery’s built-in functionality or replacing it entirely without breaking the Service Contract.
An important point worthy of highlighting is that AutoQuery Services are just normal ServiceStack Services, utilizing the same Request Pipeline, which can be mapped to any user-defined route, is available in all registered formats and can be consumed from existing typed Service Clients.
In addition to leveraging ServiceStack’s existing functionality, maximizing re-use in this way reduces the cognitive overhead required for developers who can re-use their existing knowledge in implementing, customizing, introspecting and consuming ServiceStack services.
Enables the rapid development of high-performance, fully-queryable typed RDBMS data-driven services and supports most major Relational Databases
AutoQuery Data’s Open Provider model supports multiple back-end data sources. The 3 data source providers available include:
MemorySourcewhere you can decorate the response of existing Services with AutoQuery’s rich querying capabilities.
If you’re just getting started AutoQuery we also recommend registering the AutoQuery Viewer Plugin which provides an instant UI to quickly browse and query all your AutoQuery Services that provides a fast way to explore AutoQuery features and construct AutoQuery requests through a Simple UI.
Northwind database viewer, showing how to easily expose read and cached view services of an internal dataset with ServiceStack + OrmLite
AutoQuery Viewer is a native iPad App that provides an automatic UI for browsing, inspecting and querying any publicly accessible ServiceStack AutoQuery Service from an iPad.
TechStacks OSX Desktop App is built around 2 AutoQuery Services showing how much querying functionality AutoQuery Services provides for free and how easy they are to call with ServiceStack’s new support for Swift and XCode.