Skip to content
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

Return 'null' on status 404 #57

Merged
merged 4 commits into from
Jan 31, 2018
Merged

Return 'null' on status 404 #57

merged 4 commits into from
Jan 31, 2018

Conversation

andrew8er
Copy link
Contributor

This PR changes RestClient._processResult() to return a null result to match the behavior of the documentation. It previously returned undefined. It also updates the signaure of RestResponse<T> accordingly.

André Wachter added 3 commits January 16, 2018 14:07
- Use const qualifiers
- Initialize 'result' attribute with 'null', so the code matches the documentation
- Use strict identity check for 'null' in test
@msftclas
Copy link

msftclas commented Jan 16, 2018

CLA assistant check
All CLA requirements met.

@bryanmacfarlane
Copy link
Contributor

Seems like a good change to take. @stephenmichaelf can you review?

Copy link
Member

@stephenmichaelf stephenmichaelf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@andrew8er Thanks for your contribution, we appreciate it! I added a few comments.

rres.statusCode = statusCode;
const statusCode: number = res.message.statusCode;

const rres: IRestResponse<T> = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we rename this to response or something more readable?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I retained the original variable name, but yes, this should be renamed.

@@ -38,75 +38,75 @@ describe('Rest Tests', function () {

let restRes: restm.IRestResponse<HttpBinData> = await _rest.get<HttpBinData>('https://httpbin.org/get');
assert(restRes.statusCode == 200, "statusCode should be 200");
assert(restRes.result.url === 'https://httpbin.org/get');
assert(restRes.result && restRes.result.url === 'https://httpbin.org/get');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For all of these, I am not sure it adds value to have the restRes.result check before doing an equality check. It fails either way and since this is just a test I don't think we need it. Makes it harder to read too.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment for all places this has been added.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added these checks because I usually compile code with "strict" type checking enabled. If this option is disabled, then it would produces no error message, but in my eye, it is actually semantically wrong.

assert(restRes.statusCode == 404, "statusCode should be 404");
assert(restRes.result == null, "object should be null");
assert(restRes.result === null, "object should be null");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

result object should be null?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to your documentation in https://github.com/Microsoft/typed-rest-client/blob/master/README.md a 404 should return null.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep - in the REST layer since it's job is to return a restful object, a 404 should return a null. However the http layer will return body.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'm fine with these lines / changes

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did a poor job of writing that comment. I meant that the string could be changed to be more expressive.

@andrew8er
Copy link
Contributor Author

Actually I think the whole implementation of _processResponse() is rather convoluted. I have an refactored version for which I can provide a PR in the next days, but this would be a breaking change, as it alters the method's behavior a little bit.

In the current version, exceptions from the JSON parser and response processor get swallowed and a null response is generated. I think it makes more sense to let those exceptions bubble up to the caller.

@bryanmacfarlane
Copy link
Contributor

@andrew8er - I'm fine not holding compat on "internal" underscore methods. A separate PR if you have a proposal for that.

@stephenmichaelf
Copy link
Member

@andrew8er Could you rename that variable at the top? Then we can get this merged. The null check on the tests should be fine. As @bryanmacfarlane mentioned we can do a separate PR for refactoring _processResponse(). Thanks again!

@bryanmacfarlane bryanmacfarlane merged commit d0bff29 into microsoft:master Jan 31, 2018
@andrew8er andrew8er deleted the feature/return-null-on-404 branch January 31, 2018 10:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants