New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SharePoint returns other json than proxy #9

Closed
svdoever opened this Issue Dec 1, 2016 · 17 comments

Comments

Projects
None yet
3 participants
@svdoever
Contributor

svdoever commented Dec 1, 2016

I have the following code:

<!DOCTYPE html>
<html>
<head>
    <title>Show title using REST</title>
    <meta name="viewport" content="width=device-width, maximum-scale=1, user-scalable=no" />

    <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/es6-promise/4.0.5/es6-promise.min.js"></script>
    <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/fetch/2.0.1/fetch.min.js"></script>
</head>
<body>
    <h1 id="title">Loading...</h1>
    <script>
        fetch(new Request('/_api/web/title', { credentials: 'include', headers: new Headers({"Accept": "application/json"}) }))
        .then(function(response) {
            return response.json();
        })
        .then(function(json) {
            title = json.value;
            var titleElement = document.getElementById('title');
            titleElement.innerHTML = title;
        })
        .catch(function(ex) {
            console.log('Error:', ex)
        });
    </script>
</body>
</html>

If I execute this through the proxy as index.html I get the following JSON in the body:

{"d":{"Title":"apps"}}

If I upload the page to a SharePoint document library as index.aspx I get the following JSON in the body:

{"odata.metadata":"https://macaw-my.sharepoint.com/personal/serge_macaw_nl/apps/_api/$metadata#Edm.String","value":"apps"}

Is there a way to get the data in the same format so I can develop through the proxy and switch to real SharePoint?

I found the post https://blogs.office.com/2014/08/13/json-light-support-rest-sharepoint-api-released/ for configuring the amount of meta-data, but the settings:

“accept: application/json; odata=verbose”
“accept: application/json; odata=minimalmetadata”
“accept: application/json; odata=nometadata”

don't help in getting output in the same format.

@svdoever

This comment has been minimized.

Show comment
Hide comment
@svdoever

svdoever Dec 1, 2016

Contributor

The post http://sharepoint.stackexchange.com/questions/183984/rest-call-d-results-vs-value shed some light. if I specify “accept: application/json; odata=verbose” I get the same format, but I can't get the proxy to return is the other formats like “accept: application/json; odata=nometadata”.

Contributor

svdoever commented Dec 1, 2016

The post http://sharepoint.stackexchange.com/questions/183984/rest-call-d-results-vs-value shed some light. if I specify “accept: application/json; odata=verbose” I get the same format, but I can't get the proxy to return is the other formats like “accept: application/json; odata=nometadata”.

@svdoever

This comment has been minimized.

Show comment
Hide comment
@svdoever

svdoever Dec 1, 2016

Contributor

Damn, still not exactly the the same! I now use:

fetch(new Request("http://localhost:8081/_api/web/title", 
                { 
                    credentials: 'include', 
                    headers: new Headers({"Accept": "application/json; odata=verbose"}) 
                }))

The proxy returns:

screen shot 2016-12-01 at 21 47 02

and SharePoint returns:

screen shot 2016-12-01 at 21 47 23

Contributor

svdoever commented Dec 1, 2016

Damn, still not exactly the the same! I now use:

fetch(new Request("http://localhost:8081/_api/web/title", 
                { 
                    credentials: 'include', 
                    headers: new Headers({"Accept": "application/json; odata=verbose"}) 
                }))

The proxy returns:

screen shot 2016-12-01 at 21 47 02

and SharePoint returns:

screen shot 2016-12-01 at 21 47 23

koltyakov added a commit that referenced this issue Dec 2, 2016

@koltyakov

This comment has been minimized.

Show comment
Hide comment
@koltyakov

koltyakov Dec 2, 2016

Owner

Hi Serge,

There is such a possibility that headers are different.
I've tweaked headers passby a bit and managed to get the following results:

img

"application/json; odata=verbose" - has to be inscluded to es6-promise request I believe.

Could you please check if it works for your scenarios?

Owner

koltyakov commented Dec 2, 2016

Hi Serge,

There is such a possibility that headers are different.
I've tweaked headers passby a bit and managed to get the following results:

img

"application/json; odata=verbose" - has to be inscluded to es6-promise request I believe.

Could you please check if it works for your scenarios?

@svdoever

This comment has been minimized.

Show comment
Hide comment
@svdoever

svdoever Dec 2, 2016

Contributor
Contributor

svdoever commented Dec 2, 2016

@svdoever

This comment has been minimized.

Show comment
Hide comment
@svdoever

svdoever Dec 3, 2016

Contributor

Works great, now the same result as executed directly on SharePoint! But...

The api test page now gives error:

Unhandled rejection RangeError: Invalid status code: 0
    at ServerResponse.writeHead (_http_server.js:192:11)
    at ServerResponse._implicitHeader (_http_server.js:157:8)
    at ServerResponse.OutgoingMessage.end (_http_outgoing.js:566:10)
    at ServerResponse.send (/Users/Serge/projects/serge/sharepoint-progressive-web-apps/ShowTitleProgressiveWebApp/node_modules/express/lib/response.js:205:10)
    at ServerResponse.json (/Users/Serge/projects/serge/sharepoint-progressive-web-apps/ShowTitleProgressiveWebApp/node_modules/express/lib/response.js:250:15)
    at /Users/Serge/projects/serge/sharepoint-progressive-web-apps/ShowTitleProgressiveWebApp/node_modules/sp-rest-proxy/src/index.js:166:21
    at tryCatcher (/Users/Serge/projects/serge/sharepoint-progressive-web-apps/ShowTitleProgressiveWebApp/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/Users/Serge/projects/serge/sharepoint-progressive-web-apps/ShowTitleProgressiveWebApp/node_modules/bluebird/js/release/promise.js:510:31)
    at Promise._settlePromise (/Users/Serge/projects/serge/sharepoint-progressive-web-apps/ShowTitleProgressiveWebApp/node_modules/bluebird/js/release/promise.js:567:18)
    at Promise._settlePromise0 (/Users/Serge/projects/serge/sharepoint-progressive-web-apps/ShowTitleProgressiveWebApp/node_modules/bluebird/js/release/promise.js:612:10)
    at Promise._settlePromises (/Users/Serge/projects/serge/sharepoint-progressive-web-apps/ShowTitleProgressiveWebApp/node_modules/bluebird/js/release/promise.js:687:18)
    at Async._drainQueue (/Users/Serge/projects/serge/sharepoint-progressive-web-apps/ShowTitleProgressiveWebApp/node_modules/bluebird/js/release/async.js:138:16)
    at Async._drainQueues (/Users/Serge/projects/serge/sharepoint-progressive-web-apps/ShowTitleProgressiveWebApp/node_modules/bluebird/js/release/async.js:148:10)
    at Immediate.Async.drainQueues [as _onImmediate] (/Users/Serge/projects/serge/sharepoint-progressive-web-apps/ShowTitleProgressiveWebApp/node_modules/bluebird/js/release/async.js:17:14)
    at tryOnImmediate (timers.js:534:15)
    at processImmediate [as _immediateCallback] (timers.js:514:5)

Is probably still looking to the original result set...

Contributor

svdoever commented Dec 3, 2016

Works great, now the same result as executed directly on SharePoint! But...

The api test page now gives error:

Unhandled rejection RangeError: Invalid status code: 0
    at ServerResponse.writeHead (_http_server.js:192:11)
    at ServerResponse._implicitHeader (_http_server.js:157:8)
    at ServerResponse.OutgoingMessage.end (_http_outgoing.js:566:10)
    at ServerResponse.send (/Users/Serge/projects/serge/sharepoint-progressive-web-apps/ShowTitleProgressiveWebApp/node_modules/express/lib/response.js:205:10)
    at ServerResponse.json (/Users/Serge/projects/serge/sharepoint-progressive-web-apps/ShowTitleProgressiveWebApp/node_modules/express/lib/response.js:250:15)
    at /Users/Serge/projects/serge/sharepoint-progressive-web-apps/ShowTitleProgressiveWebApp/node_modules/sp-rest-proxy/src/index.js:166:21
    at tryCatcher (/Users/Serge/projects/serge/sharepoint-progressive-web-apps/ShowTitleProgressiveWebApp/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/Users/Serge/projects/serge/sharepoint-progressive-web-apps/ShowTitleProgressiveWebApp/node_modules/bluebird/js/release/promise.js:510:31)
    at Promise._settlePromise (/Users/Serge/projects/serge/sharepoint-progressive-web-apps/ShowTitleProgressiveWebApp/node_modules/bluebird/js/release/promise.js:567:18)
    at Promise._settlePromise0 (/Users/Serge/projects/serge/sharepoint-progressive-web-apps/ShowTitleProgressiveWebApp/node_modules/bluebird/js/release/promise.js:612:10)
    at Promise._settlePromises (/Users/Serge/projects/serge/sharepoint-progressive-web-apps/ShowTitleProgressiveWebApp/node_modules/bluebird/js/release/promise.js:687:18)
    at Async._drainQueue (/Users/Serge/projects/serge/sharepoint-progressive-web-apps/ShowTitleProgressiveWebApp/node_modules/bluebird/js/release/async.js:138:16)
    at Async._drainQueues (/Users/Serge/projects/serge/sharepoint-progressive-web-apps/ShowTitleProgressiveWebApp/node_modules/bluebird/js/release/async.js:148:10)
    at Immediate.Async.drainQueues [as _onImmediate] (/Users/Serge/projects/serge/sharepoint-progressive-web-apps/ShowTitleProgressiveWebApp/node_modules/bluebird/js/release/async.js:17:14)
    at tryOnImmediate (timers.js:534:15)
    at processImmediate [as _immediateCallback] (timers.js:514:5)

Is probably still looking to the original result set...

@svdoever

This comment has been minimized.

Show comment
Hide comment
@svdoever

svdoever Dec 3, 2016

Contributor

By the way: using sp-rest-proxy in my "SPA Series" blog posts...

Contributor

svdoever commented Dec 3, 2016

By the way: using sp-rest-proxy in my "SPA Series" blog posts...

@koltyakov

This comment has been minimized.

Show comment
Hide comment
@koltyakov

koltyakov Dec 3, 2016

Owner

Do you mean that the error is faced then you try a request on default index.html (SharePoint REST Proxy Example) page?
What particular request causes the issue? I've tried a couple of basic get calls and they worked.

"SPA Series" blog posts...

Oh, it was interesting to know about your blog. Checking it out, nice posts.

Owner

koltyakov commented Dec 3, 2016

Do you mean that the error is faced then you try a request on default index.html (SharePoint REST Proxy Example) page?
What particular request causes the issue? I've tried a couple of basic get calls and they worked.

"SPA Series" blog posts...

Oh, it was interesting to know about your blog. Checking it out, nice posts.

@svdoever

This comment has been minimized.

Show comment
Hide comment
@svdoever

svdoever Dec 4, 2016

Contributor

I'm requesting /_api/web/title.
I rolled back to 1.1.5 and it was working, back to 1.1.6 and same error as above.

Contributor

svdoever commented Dec 4, 2016

I'm requesting /_api/web/title.
I rolled back to 1.1.5 and it was working, back to 1.1.6 and same error as above.

@koltyakov koltyakov closed this in af09571 Dec 4, 2016

@koltyakov koltyakov reopened this Dec 4, 2016

@koltyakov

This comment has been minimized.

Show comment
Hide comment
@koltyakov

koltyakov Dec 4, 2016

Owner

Hi Serge,

I was able to reproduce express issue message you have been facing. In my case it was wrong password hash (appeared after some experiments with Docker) to cause very similar behavior. And then I realized that there was an issue with rising real exception message.

A set of changes has been applied to the code.
Can you try the latest version (1.1.9, yep, there were some hassles that made me skip some versions)?

Owner

koltyakov commented Dec 4, 2016

Hi Serge,

I was able to reproduce express issue message you have been facing. In my case it was wrong password hash (appeared after some experiments with Docker) to cause very similar behavior. And then I realized that there was an issue with rising real exception message.

A set of changes has been applied to the code.
Can you try the latest version (1.1.9, yep, there were some hassles that made me skip some versions)?

@svdoever

This comment has been minimized.

Show comment
Hide comment
@svdoever

svdoever Dec 4, 2016

Contributor

@koltyakov it works like a breeze! Thank you so much, you are a hero!!

Contributor

svdoever commented Dec 4, 2016

@koltyakov it works like a breeze! Thank you so much, you are a hero!!

@svdoever svdoever closed this Dec 4, 2016

@ismet

This comment has been minimized.

Show comment
Hide comment
@ismet

ismet May 3, 2017

Hi,

I am having the same situation. I am developing an app using sp-rest-proxy on localhost. When I deploy it to SharePoint on-premise server, the api calls are not working since the returned data have different formats. I didn't get how you guys solve it. Btw, I'm using sp-pnp-js library for REST operations.

ismet commented May 3, 2017

Hi,

I am having the same situation. I am developing an app using sp-rest-proxy on localhost. When I deploy it to SharePoint on-premise server, the api calls are not working since the returned data have different formats. I didn't get how you guys solve it. Btw, I'm using sp-pnp-js library for REST operations.

@koltyakov

This comment has been minimized.

Show comment
Hide comment
@koltyakov

koltyakov May 3, 2017

Owner

Hi @ismet,

Can you please provide some samples of the responses diff.
It'll be easier to figure out with it. Thanks!

Owner

koltyakov commented May 3, 2017

Hi @ismet,

Can you please provide some samples of the responses diff.
It'll be easier to figure out with it. Thanks!

@ismet

This comment has been minimized.

Show comment
Hide comment
@ismet

ismet May 3, 2017

Hi @koltyakov,

I use /_api/web/title for the samples. Here are the results:

  1. Without sp-rest-proxy (http://intranet.spdev.com)
{
    "value": "Welcome Site"
}
  1. With sp-rest-proxy (http://localhost:8383)
{
    "d": {
        "Title": "Welcome Site"
    }
}

I get same results both in sending manual requests and using axios rest client.

If I add, "odata=verbose" to headers in the first scenario, the responses will be the same. However, I don't want to make default SharePoint api responses verbose.

It seems, sp-rest-proxy uses odata=verbose and I cannot change it. SharePoint uses odata=minimalmetadata and I can change it to either odata=verbose or odata=nometadata.

Is there a way to make sp-rest-proxy api responses exactly the same with SharePoint default rest api responses?

ismet commented May 3, 2017

Hi @koltyakov,

I use /_api/web/title for the samples. Here are the results:

  1. Without sp-rest-proxy (http://intranet.spdev.com)
{
    "value": "Welcome Site"
}
  1. With sp-rest-proxy (http://localhost:8383)
{
    "d": {
        "Title": "Welcome Site"
    }
}

I get same results both in sending manual requests and using axios rest client.

If I add, "odata=verbose" to headers in the first scenario, the responses will be the same. However, I don't want to make default SharePoint api responses verbose.

It seems, sp-rest-proxy uses odata=verbose and I cannot change it. SharePoint uses odata=minimalmetadata and I can change it to either odata=verbose or odata=nometadata.

Is there a way to make sp-rest-proxy api responses exactly the same with SharePoint default rest api responses?

@koltyakov

This comment has been minimized.

Show comment
Hide comment
@koltyakov

koltyakov May 3, 2017

Owner

Weird, I've never seen PnP-JS-Core returned such a format.
Quick test I've tried:

$pnp.setup({
    headers: {
        'Accept': 'application/json; odata=verbose'
    }
});
$pnp.sp.web.select('Title').get().then(console.log);

On a proxy page and on a web page results format is identical:

{
  "__metadata": {
    "id": "http://[...]/_api/Web",
    "uri": "http://[...]/_api/Web",
    "type": "SP.Web"
  },
  "Title": "Web Site Title"
}
Owner

koltyakov commented May 3, 2017

Weird, I've never seen PnP-JS-Core returned such a format.
Quick test I've tried:

$pnp.setup({
    headers: {
        'Accept': 'application/json; odata=verbose'
    }
});
$pnp.sp.web.select('Title').get().then(console.log);

On a proxy page and on a web page results format is identical:

{
  "__metadata": {
    "id": "http://[...]/_api/Web",
    "uri": "http://[...]/_api/Web",
    "type": "SP.Web"
  },
  "Title": "Web Site Title"
}
@ismet

This comment has been minimized.

Show comment
Hide comment
@ismet

ismet May 3, 2017

You are right.. For me, the problem is not PnP-JS-Core but sp-rest-proxy..

It seems, sp-rest-proxy uses odata=verbose. But SharePoint uses odata=minimalmetadata in default.

Wouldn't it be better if sp-rest-proxy provides odata=minimalmetadata response instead of odata=verbose, so we don't have to setup additional headers for custom REST operations and deal with "d" objects?

ismet commented May 3, 2017

You are right.. For me, the problem is not PnP-JS-Core but sp-rest-proxy..

It seems, sp-rest-proxy uses odata=verbose. But SharePoint uses odata=minimalmetadata in default.

Wouldn't it be better if sp-rest-proxy provides odata=minimalmetadata response instead of odata=verbose, so we don't have to setup additional headers for custom REST operations and deal with "d" objects?

@koltyakov

This comment has been minimized.

Show comment
Hide comment
@koltyakov

koltyakov May 3, 2017

Owner

I'll think about the bypassing odata mode.
You're right that a verbose mode is used in the proxy.

Owner

koltyakov commented May 3, 2017

I'll think about the bypassing odata mode.
You're right that a verbose mode is used in the proxy.

@koltyakov

This comment has been minimized.

Show comment
Hide comment
@koltyakov

koltyakov May 4, 2017

Owner

Created a separate issue for the latest comments #16 with OData modes.

Owner

koltyakov commented May 4, 2017

Created a separate issue for the latest comments #16 with OData modes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment