With my experience building web applications and services for many companies, I have found that one of the easiest and appealing engagements is to connect customers to their resources via the web. Most organizations often find that they have a data source and a whole lot of customers who want to look up their data in one or more ways.

The simplicity of using a table to list their resources and allowing the customer to query their own data however they like, is not only universally appealing but also very convenient. A manifestation of a mature solution to this problem space that is so ubiquitous across organizations is the availability of rich querying operations and simpler storage.

A table and standard query operators serve this purpose very well. When the same query operations are available on the web as methods that can be invoked with a web address identifier, it allows many devices as well as applications to consume the data in a universal way. Said another way, the absence of this manifestation indicates a potential limitation.

The language to invoke query operations over the web is with the help of web application programming interface or webAPIs for short. They conform to one or more of the following patterns for the query operations:

GET /resources?offset=0&limit=100 retrieves the first hundred records.

GET /resources?field=field1,field2 &ordering=field1retrieves just those fields and ordered by field1

GET /resources?sort=-created_at retrieves the most recent resources added pertaining to the caller

GET /resources?state=closed retrieves those resources that are no longer available

GET /resources?latitude=&longitude=&radius=

GET /resources?id={"lt": 100, "gt": 30}

GET .resource?ql=location within 500 of 40.042016, -86.900749

GET /resources?ql=select * where name = 'Fred'&limit=50 (Courtesy: usergrid.apache.org)