REST API : different properties list using /_api/Web/Lists/SchemaXml VS /_api/Web/Lists/?

Question

I tried to get the properties of list 0000000000-1111-2222-3333-444444444444 using REST. Spying the urls called from SharePoint insider (a chrome extension to query sharepoint)

I see they used two distinct url

/_api/Web/Lists(@v0)/SchemaXml?&@v0=guid%0000000000-1111-2222-3333-444444444444%27  

and

/_api/Web/Lists(@v0)?&@v0=guid'0000000000-1111-2222-3333-444444444444'&$expand=RootFolder

The first query (SchemaXml) return the list properties and fields definitions (and some server configuration in a xml format (not the easier thing to process when working with javascript)

The second one can return json. This will be easier to parse. But the second one does not have the property I'm after: MaxItemsPerThrottledOperation.

For me both queries seem to return the properties of a list. I could understand one list (SchemaXml) could contain more properties coz it's closer to the metal and some properties don't have to be exposed. What puzzles me is those queries share properties:

BaseType  
Created  
Description  
Direction  
EnableAttachments  
EnableFolderCreation  
EnableMinorVersion  
EnableModeration  
EnableVersioning  
HasExternalDataSource  
Hidden  
ImageUrl  
IrmEnabled  
IsApplicationList  
ItemCount  
MultipleDataList  
Title  

But some others properties seem to have been renamed between the twos (for unknown reasons)

BaseTemplate <=> ServerTemplate  
DefaultContentApprovalWorkflowId <=> WorkFlowId  
DocumentTemplateUrl<=>DocTemplateUrl  
Id <=> ID (with additional brackets for ID value)  
LastItemDeletedDate <=> LastDeleted  
LastItemModifiedDate <=> Modified  
TemplateFeatureId<=>FeatureId  

Some properties exist only in List

AllowContentTypes  
ContentTypesEnabled  
DraftVersionVisibility  
EntityTypeName  
ForceCheckout  
HasExternalDataSource  
IrmExpire  
IrmReject  
...   

And some properties exist only in SchemaXML

...
MaxItemsPerThrottledOperation
...

So am I right when I say you need to use both queries to get all properties of a list? Why is that?

Is there a better way to get the max allowed items per list than

    var url  = __site  + "/_api/Web/Lists(@v0)/SchemaXml?&@v0=guid%27"+listId+"%27";
    $.ajax({
        headers:{
            Accept:"application/json;odata=verbose"
        },
        url:url,
        success:function(res){
            var xmlStr = res.d.SchemaXml;
            var doc = new window.DOMParser().parseFromString(xmlStr, "text/xml");
            var xPathRes = document.evaluate ('//@MaxItemsPerThrottledOperation', doc, null, XPathResult.FIRST_ORDERED_NODE_TYPE, null);
            if (xPathRes.singleNodeValue) {
                success(xPathRes.singleNodeValue.textContent);
            }                   
        },
        error:error
    });

I find this terribly inefficient coz most of the query response is about fields defintion which I don't care of.

EDIT: I voted for ghangas' answer because (he's the only one that answered) and it answers the main question which was how to get the max allowed items per list. And the solution is

_api/Site/MaxItemsPerThrottledOperation

For the others (implicit) questions, the answers are :

• Yes, you need to use 2 queries to get list properties : because the MaxItemsPerThrottledOperation is not really a list property (or just kind of a virtual one) ; it's rather a site property. So you need to query List for basic properties then Site (or you can do it in one pass using XmlSchema and parsing xml).

• The reason for which some variables seem to be renamed between Lists vs XmSchema remains unknown (to me). I'll be glad to hear from you if their roles are different and if not, why were they renamed.

Answer 1

You have multiple questions embedded, so I will answer a couple of them with the best information I have, and leave some others to others.

The first is to get you past the JSON question: XML to JSON transform

As far as explanations for the repetitiveness is that SharePoint is built in Layers. So you will have an original server template, that may be overridden by a feature in whole or in part, and augmented by content types, and custom fields from the site or the list. So Something as simple as a list will have many different sources. If you want to find a particular piece of information you have to draw it from the correct source. Something as simple as the modified date could be redefined or relabeled by several layers. This structure may make SharePoint suck to some who just want it to do their one thing well, but the brilliance is that it can do many very flexible things well. When you get down into the weeds though you will begin to notice that trying to peel this onion apart and get the data you want may make you cry from time to time.

In this particular case, the data you want lives at the site level. Queries to the list may show such inherited things as a convenience, but you can efficiently get it from the source:

_api/Site/MaxItemsPerThrottledOperation