The goal of this post is to pin down some of the technical details of how the FileMaker Data API works to be able to make informed decisions on system architecture.
One the goals might likely be to minimize the amount of data that is transferred to just what is needed/specified.
Let us start with some background…
One of the most common use cases for the data API is to run a search and get data as a result. Behind this scenes 2 things are happening:
A query is run against a layout context. Let us call this the "query layout"
Data is returned based on a specified layout. Let us call this the "result"
Some technical details
The API has a named object called “layout”. There is also an optional named object called “layout.response”
The query is always run against the “layout”
The “result” is based on the “layout" unless that layout is overridden by a “layout.response”
It has been said that you do not have to have the fields that you are querying against on the "query layout".
What are some use cases where you would use a “layout.result”?
This is true except if you need to query against related data in portals, those have to be on the query layout. There may be a scenario where you want to filter results based on a related field but you don't actually need to return that field in your response. E.g. maybe you are trying to return a list of customers that have at least one related invoice in the past year. You could query the related Invoice table's date field (visible on the "query layout"), and then return only a few fields that exist on the layout.response layout (just the data needed to display in the list UI).
The ability to query in one context and return data from a second context was provided with the PHP/XML APIs. It's good to see that the Data API is providing continuity.
I've never heard it said that you do not have to have the fields that you are querying on the initial layout. Can you point to some references for that?
Convenience is a big reason. It's fairly easy to make layouts that provide the exact fields needed for a task. They can be fields from related tables and/or portals. You can provide a standard layout for query and then return the result from the layout that corresponds to the current function.
Bandwidth is another reason to do this. In one case, we were providing search on a botanical database. There were a large number of fields and some of those contained long text. We performed the search on a layout that was equivalent to Form View. We switched to a layout that contained the primary identifiers, equivalent to List View. That allowed us to build a list for the user who could then select an item and view the detail. The weight of the list view was less than 10% of returning results from the form view.
Security. You can control the layouts that are accessible to the web user. However, you may want to extend the ability to search across fields that are accessible on those layouts. The search can run at a higher privilege set, to obtain access to a different layout, while returning data from the web accessible layouts.
I don't have time to test at the moment. Is this something that you have done?
The layout will only return fields that are on it but that does seem to allow an attacker to start fishing and obtain positive/negative confirmation based on the search results.
So, if the user account permissions allow it, the entire table is accessible to search whether or not the fields appear on the layout. Extra fields from related tables can be added to a layout but related TOs are not accessible unless the field is placed on the layout. I had thought that a field which wasn't on the layout wasn't accessible to search.
That's very interesting. Thanks for the video. That is something that I'll take into serious consideration.