Getting response header from REST connector.

[zongzw]

If the external web app response the things via response headers instead of the response body, is there any way to get them?

Seems loopback only hands over response body to lb4-service, the header is omitted.

[zongzw]

@raymondfeng I know you may be busy, just want to draw your attention here. Thanks for your great time.

[bajtos]

@zongzw AFAICT, your conclusion is correct - templates cannot "pick" result values from response headers. However, it seems the connector is providing the entire response object in the second callback argument third callback argument (second non-error argument).

https://github.com/strongloop/loopback-connector-rest/blob/4bd6b74fb21355a574e17649fd2bb7043d03f384/lib/rest-builder.js#L530-L564

I quickly searched through the test suite and found the following test that's accessing response headers via result.headers - would that work in your LB4 service too?

https://github.com/strongloop/loopback-connector-rest/blob/0f69a08d67b58b709c9bedd4b6c6ff4ca3c50f12/test/rest-adapter-custom.test.js#L96-L98

[zongzw]

Thanks, @bajtos . That was it. Just owed you big time.

There is one more little tip to pay attention to. The headers are placed in the 3rd parameters of the callback, not the 2ed. See below.

Post the code here for others to refer to.

      let ds = new MyRestDataSource()
      let model: typeof ModelBase = ds.createModel('myNameRest');

      let response = invokeMethod(model, 'checkHeader', new Context(), [
        function (err: object, result: object, response: IncomingMessage) {
          console.log("in callback err: %o", err);
          console.log("in callback result: %o", result);
          console.log("in callback response: %o", response);
          console.log("in callback headers: %o", response.headers);
        }
      ]);
      console.log("returns from checkHeader call: %o", response);

[bajtos]

@zongzw you are right, it's the third argument. I meant "second non-error argument", sorry for the confusion.

I am happy to see that you managed to figure this out!

Would you mind contributing a pull request improving connector's README file to explain how to access response headers, so that future users don't have to search on GitHub? See the following resource to get you started: https://loopback.io/doc/en/contrib/code-contrib.html

[zongzw]

@bajtos sorry for late response. Hope you also had a good weekend.

I verified it in my test application, however, there's some obstacle for using it my product code. I found that the invokeMethod seems to be called async, thus it goes into the callback function function (err: object, result: object, response: IncomingMessage) later after RestCall returns. See here if you'd like to check.

Still working on figuring it out why it does.

Back to your question. I'm glad to do that after I make things clear.

But I still have a concern: Should not loopback-connector-rest provide the new feature of providing response headers to callers, instead of providing a workaround solution in README?

[raymondfeng]

It should be easy to introduce a setting flag to control if response or body is passed to the callback function as the result (2nd arg). Are u willing to contribute a patch?

[zongzw]

Yeah, I'll try it, now.

[zongzw]

@raymondfeng I encountered a problem when running the test. Seems it's due to google map API changes. Do you have a good proposal to solve it?

[bajtos]

I encountered a problem when running the test. Seems it's due to google map API changes. Do you have a good proposal to solve it?

This should have been solved by now, see https://github.com/strongloop/loopback-connector-rest/pull/137

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.