The Socialtables API Docs don't seem to indicate whether or not I can create tables & populate them via the API. Is it possible, and does anyone know of any docs for formatting this kind of request?
Absolutely - tables can be created for an extant event by making a POST request to our /4.0/legacyvm3/teams/{team}/events/{event}/elements endpoint. The request body should be a JSON-encoded array of floor element descriptors, which should each be composed as follows:
{
"random_id": (a UUID or other unique string),
"event_id": (the ID of your event),
"space_id": (the ID of your space),
"pos_x": (the horizontal position of your table),
"pos_y": (the vertical position of your table),
"rotation": (the desired rotation of your table),
"name": (the name that should correspond to your table, or an empty string),
"width": (the width of the table, in inches),
"length": (the length of the table, in inches),
"radius": (the radius of your table, in inches, if circular),
"layout": (specify 'table-rectangle-custom' or 'table-circle-custom' for rectangular or circular tables respectively)
}.
The event and space ID can be obtained from your event's URI, or through the event and space listing endpoints respectively. For more information, including the endpoint for creating an event, see our full list of endpoints at https://developer.socialtables.com/api-console.
Related
I'm really new to FaunaDb, and I currently have a collection of Users and an Index from that collection: (users_waitlist) that has fewer fields.
When a new User is created, the "waitlist_meta" property is an empty array initially, and when that User gets updated to join the waitlist, a new field is added to the User's waitlist_meta array.
Now, I'm trying to get only the collections that contain the added item to the waitlist_meta array (which by the way, is a ref to another index (products)). In a other words: if the array contains items, then return the collection/index
How can I achieve this? By running this query:
Paginate(Match(Index('users_waitlist')))
Obviously, I'm still getting all collections with the empty array (waitlist_meta: [])
Thanks in advance
you need to add terms to your index, which are explained briefly here.
the way I find it useful to conceptualise this is that when you add terms to an index, it's partitioned into separate buckets so that later when you match that index with a specific term, the results from that particular bucket are returned.
it's a slightly more complicated case here because you need to transform your actual field (the actual value of waitlist_meta) into something else (is waitlist_meta defined or not?) - in fauna this is called a binding. you need something along the lines of:
CreateIndex({
"name": "users_by_is_on_waitlist",
"source": [{
"collection": Collection("users"),
"fields": {
"isOnWaitlist": Query(Lambda("doc", ContainsPath(["data", "waitlist_meta"], Var("doc"))))
}
}],
"terms": [{
"binding": "isOnWaitlist"
}]
})
what this binding does is run a Lambda for each document in the collection to compute a property based on the document's fields, in our case here it's isOnWaitlist, which is defined by whether or not the document contains the field waitlist_meta. we then add this binding as a term to the index, meaning we can later query the index with:
Paginate(Match("users_by_is_on_waitlist", true))
where true here is the single term for our index (it could be an array if our index had multiple terms). this query should now return all the users that have been added to the waitlist!
I recently started experimenting with the REST API for SharePoint 2013 Foundation and I am trying to return all entries in a list. My GET request returns the data I am looking for, but the IDs used to identify the columns in the list are not helpful for identifying what the information is (see images below). The column IDs between 'Title' and 'ID', in the second image, are a jumble of characters.
SharePoint List View
Response Data
Is there any way to configure the list to use the column names as IDs? Also, is there some significance to the characters currently used as IDs?
You will need to make a second request to get a listing of columns that includes the InternalName and the Title which is what you are trying to reference:
You can use this REST call:
_api/web/lists/GetByTitle('Project Details')/fields
or you can use CSOM:
using (ClientContext context = new ClientContext(url))
{
List list = context.Web.Lists.GetByTitle("Project Details");
context.Load(list, l => l.Fields);
context.ExecuteQuery();
foreach(Field field in list.Fields)
{
Console.WriteLine(field.Title);
Console.WriteLine(field.InternalName);
}
}
SharePoint automatically generates the InternalName and it is a read-only field, at least using REST. It'll be easier to get the Field Data to correlate the InternalName to the Title than changing the values.
The column you are referring to, between Title and Id, is the ID of the content type associated to the item. It is not a column ID.
The SharePoint REST API is OData compliant, so you can use the $select parameter to query for the neccesary fields.
http://server/site/_api/web/lists('guid')/items?$select=Column1,Column2
Please be aware though, lookup fields need to be expanded as well, otherwise you get only the Id of the lookup item.
http://server/site/_api/web/lists('guid')/items?$select=LookupColumn&$expand=LookupColumn/Title
Bear with me, as I'm new to API Design and stackoverflow.
For my API design I have three main components:
key/value pairs (a singleton resource)
group (a collection of KVPs)
subgroup (a variation of the corresponding group)
In my API the user should be able to:
create, retrieve, update, and delete KVPs (basic CRUD actions)
organize KVPs into groups and access a listing of those groups
create subgroup variations of the groups that automatically inherit the parent groups' KVPs, and in those subgroups they can edit each KVPs data independently
For example, my Create a New Group request in my documentation looks like this:
{
"group": "age",
"kvps" : [
{
"key": "height",
"value": 5.2
}, {
"key": "weight",
"value": 150
}
],
"subgroups": [
"adult",
"teen",
"baby"
]
}
Using this as an example, I would like the subgroups "adult", "teen", and "baby" to have their own versions of the KVPs "height" and "weight" each with a different value (e.g. adult with a height of 6 and weight of 200, teen with a height of 5.2 and weight 140, etc.) that can be edited independently from each other.
My question: How should I structure my api so that a user could either:
have just editable kvps
have any number of editable kvps organized into any number of groups
or
have any number of editable kvps organized into groups and then further into subgroups
WITHOUT duplicating any of the data?
So far I have a uri structure like this:
/settings/kvps/{kvp_id} (CRUD on one single KVP)
/settings/groups/{group_id} (CRUD on one single group)
/settings/groups/{group_id}/kvps/{kvp_id}
/settings/groups/{group_id}/subgroups/{subgroup_id}
/settings/groups/{group_id}/subgroups/{subgroup_id}/kvps/{kvp_id}
So the kvps have 3 possible URIs, which seems messy to me, and from what I know editing the value of a kvp at
/settings/groups/1/subgroups/1/kvps/1
would also change its value at
/settings/groups/1/subgroups/2/kvps/1
/settings/groups/1/subgroups/3/kvps/1
/settings/groups/1/kvps/1
/settings/kvps/1
and so on, which is the opposite of what I want.
Any ideas?
Once again, I apologize if this is a very simple question that I am way off of, this is my first time designing an API.
When obtaining a collection of items from a RESTful web service (via GET), the representation of each single item (e.g. in JSON) usually contains the item's resource identifier. This can either be the ID of the resource or the entire URI which usually contains the ID.
This identifier (ID or URI) is required in case the client needs to further interact with the remote resource representing the single item. Many people seem to consider it good practice to provide the entire URI and not only the ID, so that the client has nothing to do with URI construction (for example, this is what Miguel Grinberg writes in this article).
But what should be done in case multiple items are to be combined in order to create a new resource? Then the client needs to tell the server which items are to be combined. And eventually, the server requires a list of IDs for processing the request. Assuming that the client retrieved URIs for each item in the first place -- where would you perform the URI parsing in order to extract the raw IDs again: in the client or in the server?
Example: the client retrieved a collection of pages in a GET request. Each page item identifies itself with an URI (containing the ID):
{
"pages": [
{
"content": "bla bla",
"uri": "/pages/1"
},
{
"content": "that is no interesting content",
"uri": "/pages/2"
},
...
]
}
Now assume that the client instructs the server to create a new resource combining multiple pages: a book, built by pages 1 and 2. The POST request body can either contain IDs or URIs:
{
"title": "A Boring Book",
"pages": [1, 2]
}
or
{
"title": "A Boring Book",
"pages": ["/pages/1", "/pages/2"]
}
In the first case, the clients needs to know the structure of the URI and extract the ID before sending the request. In the second case the server needs to extract the ID from the URI.
On the one hand, I like the idea of resources being represented on the client side by URIs only. On the other hand, I also like to keep things simple and pragmatic and why should we send entire URIs to the server when the context is clear and only the IDs are needed (the book creation does not directly act on page resources)?
What would you prefer and why? Or do you think that this is really not too important?
Do you think the following approach would be a good compromise? Client-side extraction of the ID from the URI by parsing the URI from right to left and extracting the number after the rightmost slash, i.e. assuming a certain URI structure without the need to hardcode the entire path.
I think that clients should receive absolute URLs from the server and only use these without any kind of modification. Therefore, I would even go one step further beyond your last example:
{
"title" : "A Boring Book",
"pages" : [ "http://.../pages/1", "http://.../pages/2" ]
}
Only the server should be responsible to extract Ids from URLs if necessary.
We are in the middle of designing a new feature for our API and we stumbled across a dilemma.
We have two different types of resources with a 1-N relationship.
Representations and Layers.
A Representation can contain multiple Layers. A Layer can belong only to one Representation.
The thing we are stuck with is that we need to maintain an order for the Layers in a Representation.
And we came up with two approaches:
First approach: Linked List
Each Layer knows about its previous layer. In the DB this is achieved by having a "parent" field in the Layers table that contains the id of another Layer. The first Layer will have a "parent" set to NULL.
This then is exposes through the API by the following URIs:
Create
GET /Representations/{repID}/layers
gets all the layers for a representation. The order can be worked out by going through all the layers and look at the Parent field.
POST /Representations/{repID}/layers
body:
Label: (string)
Parent: LayerId
This is used to create and insert a Layer in a specific position, by specifying the Parent in the request body. If you set Parent to NULL the newly created Layer will be the first Layer in the order.
If you omit the Parent field, the newly created Layer will be positioned at the bottom of the order.
Problem with this is that, in the response, we need to notify the api consumer that other layers have changed order because of the new insertion.
Update
PUT /Representations/{repID}/layers/{layerId}
body:
Label: (string)
Parent: LayerId
Again you can specify a new Parent to re-order the layer and again we will need to send back some information about all the other layers that have changed.
Delete
DELETE /Representations/{repID}/layers/{layerId}
need to send back some information about all the other layers that have changed.
Second approach: Layers Order as its own resource
The idea is that layers themselves don't have a notion of order. They are merely a resource.
Then you get a layersorder resource which is in charge of keeping the information about the order of the layers.
So you will still have the CRUD functionality for layers:
GET - POST - PUT - DELETE
but when you want to know anything about their order, or you want to change their order, you will use the following uri:
/Representation/{repId}/layersorder
This resource will support only two methods
GET /Representations/{repID}/layersorder
gets back an ordered list of Layers Ids in this Representation.
PUT /Representations/{repID}/layersorder
body:
[] - Array of Layers Ids in the new order.
Updates the order of the layers. you need to pass an Array of Layers ids in the new order as the body of the request. (e.g. [1,3,2,4,6,5] )
as per the first approach, whenever you add or remove a Layer you will need to notify the api consumer that another resource has been updated. In the first approach that was the list of layers affected by the change, in this approach is the new order of the layers (the layersorder resource).
I would like to hear opinions and also examples of similar situations and how you solved the problem.
thanks.
I've experienced part of what you are describing.
When doing a PUT/POST that affects an entity (or entities), I like to return the full object after the change. Hopefully the return object isn't massive, but if I were using your API, with the first approach ... I would enjoy doing a PUT/POST and updating a layer and then getting back the full Representation object with the updated Layer information.
It just makes it easy for me to confirm my changes and also start working immediately in my code with the new structure. I would dislike doing the PUT/POST and then having to do an additional GET to see the change.
For the second approach ... the more work I have to do to make an API call, the more frustrated I get. I'm not sure if I read it right, but to do a PUT with the second approach, it seems like I have to construct the entire representation and layer objects to update one piece of data. That would be frustrating.
I would prefer the syntax of the first approach, but with the concepts from the second. In other words, this is the document I would expect to see after a PUT/POST/GET:
{
"type" : "Representation",
"id" : 1,
"layers" : [
{ "id" : 1, "name" : "the first layer", "order" : 1, "parent" : "" },
{ "id" : 2, "name" : "the second layer", "order" : 2, "parent" : 1 },
{ "id" : 3, "name" : "the third layer", "order" : 3, "parent" : 1 }
]
}
It's sorted for me already so I don't have to do that work, but also has the information used to produce the sorting just in case. I've done this with REST APIs and it seems to work great for the users.