We were discussing the use of a table and standard query operators to allow users to lookup resources over webAPIs which can be invoked from any device or application. In fact, any other way to perform lookups of resources over the web may be rather limiting.
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)
The purpose of using urlpatterns like above is that they standardize the operations and format for any dataset.
The purpose of using urlpatterns like above is that they standardize the operations and format for any dataset.
If we had resources described by a composite key with more than one attributes, we can make it even more granular with the addition of more columns to the key. This will not affect any of the existing data and will make the query operation even more specific. The convenience of a table to add features for querying is already well-known. In addition, the standard timestamps of created, modified and status might also help with passing the querying logic to the client so they can construct any url patterns. If the clients are internal, they can even specify the entire logic on a sql statement. to the resource.
Tables are also stored in database where the index based lookups are very efficient. Furthermore, there is no limit to the number of records the table may have. However, it might be prudent to archive older unused records to keep the table to a smaller size.
Tables are also stored in database where the index based lookups are very efficient. Furthermore, there is no limit to the number of records the table may have. However, it might be prudent to archive older unused records to keep the table to a smaller size.
No comments:
Post a Comment