Misleading and confusing REST API detail response received when ACLs restrict access

The REST API detail response received when ACLs restrict access is misleading and confuses users. The detail in the response is "No. of records constrained due to ACL restrictions" whereas the value has to be calculated based on the sysparm_offset and sysparm_limit parameter values.

1. Go to the following URL:

   /sys_security_acl_list.do?sysparm_query=name%3Dincident%5Eoperation%3Dread

2. Deactivate all the incident read ACLs and just create a new ACL with the following values:

   Name: incident.none
   Operation: read
   Admin Overrides: False
   Advanced: True
   Script: answer = false;

3. Go to /$restapi.do and set the following REST API options:

   Retrieve records from a table (GET)
   Table Name: incident
   Add query parameters with the following details: sysparm_limit = 1 and sysparm_offset = the number of incident records in your instances that you are using to test subtracted by 1

4. Click Send.

   Access the URL in the message that appears:
   HHTP METHOD / URL ==> GET https://<instance-name>.service-now.com/api/now/table/incident?sysparm_limit=1&sysparm_offset=sysparm_offset number from step 4
   
   The HTTP status code is 403 Forbidden.
   
   Message expected to be displayed:
   <detail>sysparm_limit record(s) constrained due to ACL restrictions</detail>
   
   Actual message that is displayed:
   <detail>sysparm_offset + 1 records constrained due to ACL restrictions</detail>
   
   This message can be misleading because you would expect only the number of records being queried up to a limit, not more than the limit. The issue does not occur again when you try to query for the number of additional records that exist like sysparm_limit=1&sysparm_offset=sysparm_offset number from step 4 + 1 or 2, and so on, which correctly indicates no records or zero records.

There is no workaround for this issue. After carefully considering the severity and frequency of the issue, and risk of attempting a fix, it has been decided to not address this issue in any current or future releases.