You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
AutoQuery Data's Open Provider model supports multiple back-end data sources. The 3 data source providers available include:
AutoQuery Memory - for querying static or dynamic in-memory .NET collections, some example uses include showing querying a flat-file .csv file and querying a throttled 3rd Party API with it's built-in configurable caching.
AutoQuery Service - a step higher than MemorySource where you can decorate the response of existing Services with AutoQuery's rich querying capabilities.
AutoQuery DynamoDB - adds rich querying capabilities over an AWS DynamoDB Table, offering a giant leap of productivity than constructing DynamoDB queries manually.
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.
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.