If performance is of the essence, I would probably recommend GetTrendDataForParameter. This returns the SLNet raw response and does no custom parsing inside the webapi. You have no option to choose which type of trend (avg vs realtime) it will fetch, but by default, it will request average trend data, so that's fine for your use case. It also doesn't allow to fetch a custom time span window. So only last hour, day, week, ... is supported by this call. The GetTrendDataForParameterByName will use previous method behind the scenes, by will do a lookup by name first, so if you know the IDs up front, this one is not recommended. These two methods will throw an error on the request if something would fail. While the other methods will never throw an error, but include the error message in the Error property of the response. Note: The table index has to be the display key (except advanced naming).

GetTrendDataForTableParameter does a bit more validation, will auto pick the trend type (realtime vs avg), does parsing of the result to DMATrendData and allows cancellation. The GetTrendDataForTableParameterV2 does the same as the previous one, but allows to force realtime trend data, while the other will give priority over average data. The "Table" part is misleading, as it will perfectly manage to fetch trend data of standalone parameters. These two methods are the only ones that support Parameters of measurement type string.

GetTrendDataSimplifiedForParameter just parses the result of the GetTrendDataForParameter to DMATrendData and only allows providing a sliding window with the current time and end (last hour, day, week, ...). GetTrendDataCustomTimespanForParameter is basically the same as the simplied one, except for its capability to pick a custom time span (from/till) instead of a sliding window.

Our web apps make use of the GetTrendDataForTableParameterV2 because we need to allow to force either realtime or average trend data depending on the setting in the app, its async/cancellation benefit, and the fact that we need to be able to display any custom time slot. But for your use case this is probably just overhead.

Note: none of the methods allow to force 60 minute time intervals. The interval is auto picked depending on the total span. But for one week windows, it will most likely be 1 hour intervals anyways.

In short:

• if the "one-week period" is a full week (monday to sunday): GetTrendDataCustomTimespanForParameter
• if the "one-week period" is last 7 days (up till now): GetTrendDataForParameter