Sometimes the names we use in the REST API are not really ideal for the client libraries. Consider the case of Boolean properties. In .NET client libraries, the convention is to start Boolean property names with a prefix like "Is" or "Has". However, you wouldn't really want to clutter up a JSON REST API with these prefixes. For example, a property named "searchable" in the REST API ought to be named "IsSearchable" in the .NET client.

As another example, consider the OData V4 parameter $count. It's a Boolean parameter that indicates whether to include the total count of results of an OData query in each page of results. However, the name is not very suggestive. In a client library a more descriptive name like "IncludeTotalCount" might be more appropriate. In this case, the choice of name in the REST API is imposed by the OData protocol, so renaming it for the sake of a better client SDK experience is not an option (for a REST API with non-trivial production usage, renaming things is rarely a realistic option).