Option to receive "requests" library response

Description

Original title:
"Option to receive 'requests' library response"

When using the Synapse client to make rest requests, since no http status is returned one can get into a confusing state. For example, if `syn.restGET('/teamMembers/1234567)` is called where 1234567 is the team id, and let's say that team id is invalid, the response looks like `{'totalNumberOfResults': 0, 'results': []}`. This leaves app development in an indeterminate state – does the team exist? Or does it exist and have no members? I would like to be able to retrieve the underlying `requests` response, so that I have access to its fields like `ok` and `status_code` as well as its `raise_for_status` method.

Environment

None

Activity

Show:
Jordan Kiang
July 28, 2020, 4:25 PM

and I discussed the possibility of passing an additional kwarg when using the raw Synapse rest functions indicating to return the uninterpreted response object which would be a non breaking change that would support this.

Note however that in the case of /teamMembers endpoint the result with an invalid team id will be a 200 with an empty list from the backend even if the team does not exist, so this change would not provide a response object with 404 in that particular case since that is not the behavior of the underlying rest API. The /team endpoint by contrast does return a 404 for an invalid team id.

Bruce Hoff
July 28, 2020, 6:55 PM
Edited

I took the liberty of changing the title to describe the problem (rather than the suggested solution). If we are trying to differentiate between an empty team and an invalid team id then I feel this is a back end issue. (Jordan hits the nail on the head, saying that the information is not returned by the back end.) If you agree, please move this to the PLFM project and I will prioritize and assign the issue.

Tess Thyer
July 28, 2020, 7:08 PM

There are two issues here. You’re correct there’s an underlying problem with the particular endpoint I used as an example. However, while I wrote the description using the specific example of the indeterminacy of the team member list response, I would generally prefer to receive responses with standard HTTP status codes because everyone knows what those mean, and knows how to handle them. I was not asking that you fix an issue with just one endpoint. I would prefer for my original suggestion to be captured somewhere. If it’s not something you want to do, can we discuss that?

Bruce Hoff
July 28, 2020, 7:21 PM

> I would prefer for my original suggestion to be captured somewhere.
Certainly. I would still like to phrase it in terms of the issue that we are seeking to address.

Jordan Kiang
July 31, 2020, 2:14 AM

Bruce created a separate issue to track /teamMembers not returning a 404 https://sagebionetworks.jira.com/browse/PLFM-6390

Assignee

Jordan Kiang

Reporter

Tess Thyer

Labels

None

Validator

Bruce Hoff

Development Area

None

Release Version History

None

Priority

Major
Configure