REST API - doQuery - get record ids
How can I get record ID's for 'data' returned? In the XML version I would specify rid=true or similar. What do we do now to return field id=3?
Thanks, ~Rob -----------------------------...
Forum Discussion
Hi Rob,
From the help, the
------------------------------
Doug Henning
------------------------------
From the help, the
select is an array of field ids for the fields that should be returned in the response. If empty, the default columns on the table will be returned. So just include 3 for the record id.{
"from": "bck7gp3q2",
"select": [
1,
2,
3
],
...
Hope that helps!
------------------------------
Doug Henning
------------------------------
The Record ID is a pretty important field. I think it should be returned in the default set of fields. I've just wasted a day trying to figure out how to create a record that has a relation to another table. If the Record Id was returned it would have been evident that is what I need to use in the related field.
It is also not clear from the JSON API developer portal that you can do "select": ["a"] as part of your query which would also be very helpful to know.
Once you've done a "select all" you can quickly see what data you have in the fields and then change the select to only the ones you need.
------------------------------
Oliver Polden
------------------------------Thanks, Doug.
That is helpful. I guess I didn't think of SELECT acting as CLIST from the old api.Do you know if there is a 'give me all fields' option? Used to be
clist = 'a';
------------------------------
Rob White IV
------------------------------- Hey Rob, I don't think that's possible in the REST API. Do you really need all the fields? It's best to only select the ones you need to minimize the amount of data retrieved.
------------------------------
Doug Henning
------------------------------- Hey Doug!
Sorry to bother you so much with all this. Thanks for engaging with me.
I do need all the fields, due to my implementation of my data across a variety of non-quickbase programs that treat my quickbase instance more like a standard database, rather than a slick no-code solution.
I don't want websites spamming the QuickBase API, so my process to date has been to pull the data down intermittently, format it for template consumption by a website across a variety of platforms, then display it to the user (or general public, depending on the case).
This allows me to provide a variety of caching mechanisms that I control based upon need. Also, I get to normalize the output in a manner that is a bit easier to deal with than what is provided from the API. I'd hate to think I will have to run expensive transform functions on each route at some point. Anyhow, I'll come up with something. Here is an interesting tidbit I ran across during this thought experiment that I want to share. For what it is worth...
Testing from the docs Quickbase API Portal
I went to a table with only a few fields. 19 total. 14 in the default report.
I ran the query with SELECT set to an empty array.
I got 14 fields.
However, for the 'why not' factor, I set the SELECT value to 'a'.
and got...
Seems 'a' still works. Whether intended or not, I dunno. Just FYI.
Hopefully they'll let me know before they patch it and break my stuff. I'm going with 'a' for my use for now. :)
Thanks again,
~Rob
------------------------------
"The" Rob White IV
------------------------------
