Tutorial: Data and urls

Step by step Data and urls

When a new [[service]] application is created, it is assigned its own corresponding URL.

For example, if you were to create a chat application, it could live at :

[[baseUrl]]/base/mychat

Every piece of data inside your application is addressable by URL. For example, here's a depiction of a mychat base with a title and two users:

  • mychat ⇐ [[baseUrl]]/base/mychat
    • title: "My super chat !" ⇐ [[baseUrl]]/base/mychat/title
    • users
      • robert ⇐ [[baseUrl]]/base/mychat/users/robert
        • name
          • first: "Robert"
          • last: "Martin"
      • john
        • name
          • first: "John"
          • last: "Doe" ⇐ [[baseUrl]]/base/mychat/users/john/name/last

We refer to these URLs that point to data as locations. Locations can store strings, numbers, booleans, or nested children.

Nested children allow you to structure your data hierarchically. For instance, mychat has a list of users, which are located at:

[[baseUrl]]/base/mychat/users/

The data for users robert and john is stored at these nested locations:

[[baseUrl]]/base/mychat/users/robert

[[baseUrl]]/base/mychat/users/john

In this example, robert and john are said to be children of users, and users is said to be the parent of robert and john'. Note that locations can contain either data (a string, number, or boolean) or children, but not both.

Locations for data can nest as deeply as you like. For example, the last name for user robert is located at:

[[baseUrl]]/base/mychat/users/robert/name/last

When creating a new nested location, any parents which don't currently exist will be automatically created. If you want to add another user, you can set the following path to the string Mike and the parent locations '/users/mike' and '/users/mike/name' will be automatically created.

[[baseUrl]]/base/mychat/users/mike/name/first

If you remove the value for first which you just set, the parents (which now contain no children with data) will be automatically removed and our application data will be the same as before adding the new user.

Charset limitations

A Webcom reference has two key parts: the [[service]] application Name and the child Path (optional).

[[baseUrl]]/base/<Name>/<Path>

Name

The Name may contain any unicode characters except:

  • . (period)
  • $ (dollar sign)
  • [ (left square bracket)
  • ] (right square bracket)
  • # (hash or pound sign)
  • / (forward slash)
  • ASCII Control Characters (0-31 and 127)

Path

The child Path has the same character restrictions, with the exception of / (forward slash).

The / is allowed and is used to specify a child Path (for example: /user/first/name).

Key order

Key order is defined as follows:

  • Keys that are parsable as integers are ordered before others.
  • Integer keys are ordered following natural order on integers.
  • Other keys are considered as strings and ordered in lexicographical order.

Example: 0 < 1 < 9 < 72 < 521 < 1000 < "aa" < "bb"