as i said I'm just learning. I'm writing a webapp to allow the user to search for and list some customers. if I use the suitetalk api, i can use the /customer api with the q= to filter. howerver that just returns a list of IDs of matching customers, then iiuc, i have to itterate through that list to get details of each customer. Is this the best approach? or is it better just to make a custom suiteql query to use sql select to retrieve customers and IDs matching user search criteria, along with useful fields for presenting to the user?

Check this api response https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_157909186990.html

yes, I guess I'm really just thinking about best approaches. I feel like the rest API could be good but seems to be missing some useful functionality. Like it's annoying to filter to get a list of customers and then have to iterate through the list to retrieve useful details about the customer just to display to the user. Maybe I'm missing something

@JBL The query should extract the information the user only needs. That way you don't need to iterate the result. The beauty with SuiteQL, you can extract the data you need without scripting, provided that the data you need is supported.

ok. so what is the point of the rest api then if we all just fall back to using suiteql?

I like the REST API for fast record insert. Don't have numbers, but for me is way faster than restlets or csv imports. Also, developers in my team are used to APIs and if not needed, they don't bother creating and mantaining a script as an endpoint.

i see, thanks for the explanation Edgar, makes sense

"is it better just to make a custom suiteql query to use sql select to retrieve customers and IDs matching user search criteria, along with useful fields for presenting to the user?" My opinion here: using custom SQL will allow you to define the data you need and eliminate the issue "i have to itterate through that list to get details of each customer". If you want, you can build your own custom RESTlet to execute your query and process the output based on what is needed and your requestor doesn't need to post-process the response.

yes i see, thank you. that does make sense.