HELP & Documents

[...]




Date: 2017.6.13        Author: Admin

Search index: (title and article description search)

No record was found!

Document storage API


Document Storage API


RESTful API

Data is stored into a webdo.com user account CLOUD storage.
Storage location: Applications/<app folder>/<folder>/data/<data location/table>.

This is a KEY based document storage, we will refer to documents in the collection as records and the document KEY as ID. While it can perform QUERY, it is not wise to overuse on large collections because there are no index files at this time.

Can perform next operations:

                CREATE, READ, UPDATE, DELETE known as CRUD

It offers up to one GB of storage per table and allows very fast read access for virtually unlimited connections. Write operations minimum speed is 5/second.
Charges are per 10000 API requests, see your control panel billing information.

Requirements:

- register one application with WEBDO.COM

        - code
        - folder
        - additional info

-  user authorization ( check WEBDO.COM Open Authorization )

All operations requires an authorization header like:

Authorization: Bearer <token>

CREATE:

Headers:

Authorization: Bearer <token>

Method: POST

URL: https://q-ube.com:45567/dbs/

Data:

         { "appkey":<app key>,
           "basefolder":<application folder>,
           "folder":<folder name>,
           "table":<table name>,
           "data":[<records array>]
        }   

"records array" an JSON array of records to be inserted into the table.
Restricted fields: id (id field should be created and maintained by the API services)

"basefolder" can be "m" or "l", difference relates to where the data is stored on app key master drive or local on  authenticated user drive. It depends on your web application requirements to chose your data storage location.

Response:

JSON object:

{
    msg:<message>,
    response:{
        allok:<true/false>,
        data:[ok data list],
        rejected:[rejected records],
        nores:[NO response list, file is in use - try again later !]
}

  1. { // sample one insert record ...
  2.    "msg": "write data",
  3.    "response":
  4.    {
  5.        "allok": true,
  6.        "data":
  7.        [
  8.            {
  9.                "start": "is working ...",
  10.                "id": "aa5",
  11.                "_xt": "2017-06-13T09:14:21.540Z",
  12.                "_action": "create"
  13.            }
  14.        ],
  15.        "rejected":
  16.        [
  17.        ],
  18.        "nores":
  19.        [
  20.        ]
  21.    }
  22. }



UPDATE:

Same as CREATE, the difference is that each record in records array you need to update should have a defined <id> field and one additional field "_action" having value "update".
You CAN NOT update specific fields/information on one record, in order to update you should send the entire record.

DELETE:

Same as CREATE, the difference is that each record in records array you need to delete should have a defined <id> field and one additional field "_action" having value "delete".

CREATE, UPDATE, DELETE operations can be sent together into one <records array> respecting previous defined restrictions.

READ:

Headers:

Authorization: Bearer <token>

Method: POST

URL: https://q-ube.com:45567/getdbs/

Data:

         { "appkey":<app key>,
           "basefolder":<application folder>,
           "folder":<folder name>,
           "table":<table name>,
           "params":{<params object>}
        }  

params object:
- action: action

action is one of next ["query", "getlast", "getlastfrom", "getnew", "info"]

additional params object items:
- last (used with action = "getlast" or action="getlastfrom", numeric)
- lastfrom (used with action = "getlastfrom", string - is the record "id" you get records from)
- lastrecord (used with action = "getnew", string - is the record "id" that limits the new records set)
- filters (used with action="query", array of objects:
                     [ {"field":<fieldname>,"value":<value>},...]


SAMPLE:
params: {
        action:"getlast",
        last:100
    }


will return last 100 records sorted descending by "id/creation date"

Response:

{

    request:{<request data>},
    records:[<records list>],
    errors:[<errors list>],
    total: <cont of records>,
    lastrecords: <last record id>

}

You may use the FireFox add-on RESTClient to test the services in place.



















Loading data

Loading WordBricks ...


Powered by