I just wanted to start by saying that the tool your create is really great.
I have a question regarding the REST APIs and the services that can be created in Backendless.
By default data objects return a bunch of details related to the properties each store as well as relations. I found out that fields can be limited by setting/excluding properties, however I coudn’t manage to make it work for the relation tables.
I was looking at this guide, which shows how to approach this from the HTTP request but I am not sure if this can be done from Backendless.
I was trying to exclude properties by passing property_name.field_name (from the linked table) but this didn’t seem to work (suprisingly when I was giving wrong field_name the error was beeing thrown so I believe there must be some kind of validation in place?).
Please let me know if you can advise on above whether it is currently possible on the Backendless or if that has to be coded (I do not really want to make those calls with all parameters beeing passed directly from the mobile app, I would prefer to keep that logic on server in services).
First of all, welcome to the Backendless community and thank you for your kind words.
To be able to assist you, could you please describe the data structure you have (perhaps by attaching a screenshot of the SCHEMA tab for the tables in question) and then describe what end result you’d like to have.
I don’'t want nessecary to share the schema that I’m working on so I’ll use an example (if you would prefer screenshots anyway, then please let me know, I’ll create some dummy one).
Let’s say I have
Car table, which has fields like:
numberOfDoors [integer]
type[string]
name [string]
colour [object reference to Colour table]
Colour table, which has fields like:
red
green
blue
Taking that dummy example, when I would create an API call, with relation it would return json which would have
__jsonClass: Car
objectId: XXX
type: XYZ
colour: [ {
red:
green:
blue:
} ]
Now, let’s say for each API call I do not need to know all 3 fields from Colour table and the “red” would be enough. How can I limit the properties that the would appear on the payload for relation? This is duable for the main table which is “Car” but I am unable to do the same for any table that pops up based on the object reference.
Thank you, this is helpful. Rather than excluding properties, I would recommend creating a list of properties you’d like the backend to return. In this case, it would look like this (when you send a request to the Car table:
The link which you sent describes similar things as the one that I attached in the main page - the question is how this can be set by codeless to avoid sending those through REST API and just predefine in backendless service, can that be done or the custom code needs to be written?
There is “Load Table Object” block and it has various selections that can be done but as I passed (refering to the example): colour.red in the properties section it didn’t work (but in the same time it worked fine for any property inside the “Car”)
Sorry for the delay but I was doing some more tests using both codeless and REST APIs and it seems that there is some issues for both (or just functionality does not cover the operations yet).
Can you please confirm whether user should be able to call REST API to object retreival (as a list of objects) whereas each object has a 1:N relation and there is a way to pass in query parametrs to:
return only 1:N relation from the child table?
specify the pagination for the 1:N results and not for the “main” list?
Example:
Person object (that has properties: name, age, address with 1:N relation to Address objects)
Calling: data/Person/
Use case 1: I would like to use “props” to specify the properties from Person that should be visible in the payload response. Right now when I would specify property as address.name, the API would return not the array but the first adress object in the relation (eventhough it is 1:N). Is there a way in the REST API query to specify that as 1:N?
Use Case 2: Let’s say that each Person object may have infinite number of addresses assigned to it. I would like to have a query that would list all persons objects that I have in the database with addresses pagination applied to it. E.g.: I have 3 different “persons” object, first has 10 addresses, second have 50 addresses and third has 200 addresses. I know that in backendless REST API I can specify pagination for specific relation by doing: data/Person//address&pageSize=5 but can the same be applied when I do not want to provide objectId and just list all (or based on specific where clause) just some parent objects?
Mark - regarding the screenshot, I believe I would need to first figure out those 2 above use cases in REST API itself and then move to codeless to just test it there if it will be required at later stage.
Hello Mark - it was an example. In the app, I am looking at the Restaurant table and the RestaurantTypes. When I am trying to show just few properties from restaurant + just restaurantType array (with both assigned values) the whole restaurant schema pops up.
For use case 2 - thank you for the link. Does it mean that the only way to do what I am lookng for is to invoke 2 separated calls, first to get (refering to the example) each person object_id and then to call the pagination for each person? Based on example I would have one call to list all persons and then 3 calls (one per person) to get addresses with applied pagination?
Thank you. Can you please replicate the same starting from UserSavedLists table?
UserSavedList has a link to Restaurant and Restaurant has a link to Types. While starting from this “UserSavedList” I am unable to replicate this - is that cause that the properties does not work for the deeper relations?
Did you run above? I have and those are not working as expected and that is the main issue. I would expect to receive similar response as the one from your previous post but this returns 4 arrays (instead of 2 for each restaurant) and it returns just the first restaurant type (but the relation is 1:N and it has more than one available).
Yes, I ran both queries. For the first one, since the response is flattened (restaurant type is returned as a property, you all possible combinations. For example, say you have the following objects:
UserSavedList:
BobsList
and BobsList references multiple restaurants with the following types:
RestaurantType
FastFood
Fine Dining
When the structure is flattened, you get the following two objects: