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 :
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
- robert ⇐ [[baseUrl]]/base/mychat/users/robert
- first: "Robert"
- last: "Martin"
- 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:
The data for users
john is stored at these nested locations:
In this example,
john are said to be children of
users is said to be the parent of
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:
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.
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.
A Webcom reference has two key parts: the [[service]] application
Name and the child
Name may contain any unicode characters except:
[(left square bracket)
](right square bracket)
#(hash or pound sign)
- ASCII Control Characters (0-31 and 127)
Path has the same character restrictions, with the exception of
/ (forward slash).
/ is allowed and is used to specify a child
Path (for example: /user/first/name).
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"