Use "map of string" for query_parameters

[cwe1ss]

Hi! The current syntax for query_parameters uses a "map of list of string". I know it's the same in AzAPI but I'm wondering if there really is a reason to use this complex format, or if you could reconsider this for msgraph and use a simple map instead? I pretty much always forget the brackets :(

It's also confusing because headers uses "map of string".

# Current syntax
query_parameters = {
  "$select" = ["id,mailNickName"]
}

# Proposed syntax
query_parameters = {
  "$select" = "id,mailNickName"
}

[ms-henglu]

Hi @cwe1ss ,

Thank you for taking time to report this issue.

You're right that having headers as map[string]string while query_parameters is map[string][]string creates an inconsistency. However, this reflects the different nature of these HTTP components:

• Headers: While HTTP technically allows duplicate headers, most frameworks merge them or treat them as single values
• Query Parameters: Commonly support multiple values for the same parameter name

I'd recommend the below syntax for multiple values for query parameters:

query_parameters = {
  "$select" = ["id", "mailNickName"]
}

[cwe1ss]

Thank you for your reply, it's much appreciated.

While I understand this from a HTTP spec-point, I have multiple issues with it:

1. Using your syntax for $select makes it harder to copy & paste the the value into the graph explorer for debugging reasons.

2. It's more to type and not necessarily easier to read.

3. It doesn't make sense for many of the odata parameters, which are single-valued by nature - e.g. $top, $limit.

4. The same syntax does not work for $filter where, given the array, one would expect to be able to combine conditions with the following code:

data "msgraph_resource" "groups" {
  url = "groups"

  query_parameters = {
    "$select" = ["id", "displayName"]
    "$filter" = [
      "mailEnabled eq false",
      "securityEnabled eq true",
    ]
  }

  response_export_values = {
    all = "@"
  }
}

However, since you just combine the values with a , instead of the required and for this parameter, this results in the following error:

│ GET https://graph.microsoft.com/v1.0/groups
│ --------------------------------------------------------------------------------
│ RESPONSE 400: 400 Bad Request
│ ERROR CODE: BadRequest
│ --------------------------------------------------------------------------------
│ {
│   "error": {
│     "code": "BadRequest",
│     "message": "Invalid filter clause: Syntax error at position 21 in 'mailEnabled eq false,securityEnabled eq true'.",
│     "innerError": {
│       "date": "2025-08-05T07:09:50",
│       "request-id": "07f0b98e-8719-440a-a8af-e67b216585c6",
│       "client-request-id": "07f0b98e-8719-440a-a8af-e67b216585c6"
│     }
│   }
│ }

[wenzel-felix]

In my opinion, it makes sense to align it with other MS SDKs. E.g. the Graph Golang SDK: https://learn.microsoft.com/en-us/graph/sdks/create-requests?tabs=go

Here it is used this way:

filterValue := "subject eq 'Hello world'"
query := users.ItemMessagesRequestBuilderGetQueryParameters{
    Select: []string{"subject", "sender"},
    Filter: &filterValue,
}

Essentially, every parameter is defined separately and with a dedicated type.

As I understand, we want to keep it more generic, so we should at least outline the correct usage.

data "msgraph_resource" "groups" {
  url = "groups"

  query_parameters = {
    "$select" = ["id", "displayName"]
    "$filter" = [
      "mailEnabled eq false and securityEnabled eq true",
    ]
  }

  response_export_values = {
    all = "@"
  }
}

Or

And here I agree with @cwe1ss, just tell the user to provide a properly joined string. In fact, all the users of the provider have access to a join-function, allowing them to prepare the strings on their end dynamically joined based on the query parameter they use.

@ms-henglu, what do you think?