Чувствительны ли регистр Microsoft Graph к PATCH (обновление) полей элементов списка?

Question

При попытке вызвать конечную точку API элемента обновления на графике Microsoft имена полей чувствительны к регистру. Документация здесь https://docs.microsoft.com/en-us/graph/api/listitem-update?view=graph-rest-1.0&tabs=http не указывает на это. Чувствительны ли запросы к конечной точке / fields?

Я пытаюсь обновить однострочное текстовое поле с именем «Status» (внутреннее имя и отображаемое имя - «Status» (заглавная буква S). При вызове /v1.0/sites/ {id} / lists / {id} / item {id} / конечная точка поля из Graph Explorer со следующими ошибками вызова:

{
    "status":"testing"
}

Возвращается следующее.

{
    "error": {
        "code": "invalidRequest",
        "message": "Field 'status' is not recognized",
        "innerError": {
            "request-id": "8700ae5d-f2e5-4138-891a-f980630aa7d1",
            "date": "2020-05-02T15:30:14"
        }
    }
}

Однако, если тело запроса PATCH имеет следующий вид:

{
    "Status":"testing"
}

вызов завершается успешно и возвращает обновляемый элемент, все поля и правильно обновленное поле «Статус».

Учитывая, что Я вызываю API напрямую из C# (используя HttpClient и пока НЕ ​​использую SDK, поэтому FieldValueSet здесь не вариант) и использую CamelCasePropertyNamesContractResolver для JsonSerializerSettings со следующим кодом:

var request = new HttpRequestMessage(method, $"{graphEndpoint}{version}{uri}");

if (!string.IsNullOrEmpty(body))
{
    request.Content = new StringContent(body, Encoding.UTF8, "application/json");
}

var response = await _httpClient.SendAsync(request);

и тело всегда в случае верблюда и терпит неудачу. Является ли это ошибкой? и если нет, то что считается лучшей практикой для этого, так как большинство вещей, которые я пробовал (JObject и другие), кажутся действительно возвращенными компенсация взлома.

Answer 1

Для тех, кто ищет окончательный ответ, я использую следующее.

Внутри класса я определяю распознаватель случаев по умолчанию и верблюдов.

private readonly JsonSerializerSettings camelCaseJsonSettings = new JsonSerializerSettings { ContractResolver = new CamelCasePropertyNamesContractResolver() };
private readonly JsonSerializerSettings defaultJsonSettings = new JsonSerializerSettings { ContractResolver = new DefaultContractResolver() };

В рамках метода, который выполняет вызов, я просто выбираю, какие настройки использовать на основе метода Http и URI, содержащих SharePoint на данный момент.

if (body != null && (method != HttpMethod.Get || method != HttpMethod.Delete))
{
   if ((method != HttpMethod.Post) && (uri.Contains("/sites/"))) 
   {
      // Serialize the body to be pascal cased due to SP Bug
      payload = JsonConvert.SerializeObject(body, defaultJsonSettings);
   }
   else
   {
     // Serialize the body with camelCasing 
     payload = JsonConvert.SerializeObject(body, camelCaseJsonSettings);
   }
}

Answer 2

Это известная проблема с API-интерфейсами SharePoint в течение довольно долгое время . В API Graph Graph имеется связанная ошибка, в частности, в случае верблюда Graph в именах столбцов.