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

generic API responses #1823

Merged
merged 29 commits into from
Jul 2, 2020
Merged

generic API responses #1823

merged 29 commits into from
Jul 2, 2020

Conversation

bogdan-rosianu
Copy link
Contributor

@bogdan-rosianu bogdan-rosianu commented May 29, 2020

Changed the API response structure for all existing routes to include 3 fields:

  • Data (which will contain the desired result if the request was successful)
  • Error (which will contain the error message or nothing otherwise)
  • Code (which will be both human and machine-readable string and will tell the code of the response - example: bad_request)

@bogdan-rosianu bogdan-rosianu added the type:feature New feature or request label May 29, 2020
@bogdan-rosianu bogdan-rosianu self-assigned this May 29, 2020
@miiu96 miiu96 marked this pull request as ready for review May 29, 2020 12:43
Copy link
Contributor

@iulianpascalau iulianpascalau left a comment

Choose a reason for hiding this comment

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

partial review

api/address/routes.go Outdated Show resolved Hide resolved
api/address/routes.go Outdated Show resolved Hide resolved
c.JSON(
http.StatusOK,
core.GenericAPIResponse{
Data: gin.H{"details": details},
Copy link
Contributor

Choose a reason for hiding this comment

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

why wrapping it again?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

in order to group them under a functionality/component. I did the same everywhere. I might rename details to metrics

Copy link
Contributor

Choose a reason for hiding this comment

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

no, the ideea from the meeting was that, under the "data" field we should have the raw object. That is what I have understood. @ccorcoveanu ?

Copy link
Contributor

Choose a reason for hiding this comment

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

A cleaner approach is to have this extra property wrap inside data, this way the response is verbose enough so you know what you are getting back.

c.JSON(
http.StatusOK,
core.GenericAPIResponse{
Data: gin.H{"details": details},
Copy link
Contributor

Choose a reason for hiding this comment

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

also here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

in order to group them under a functionality/component. I did the same everywhere. I might rename details to metrics

@miiu96 miiu96 changed the title generic API responses (WIP - unit tests remaining) generic API responses Jun 1, 2020
shared.GenericAPIResponse{
Data: nil,
Error: errors.ErrInvalidAppContext.Error(),
Code: string(shared.ReturnCodeInternalError),
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 you can make Code inside GenericAPIResponse of ReturnCode type so you would get rid of all this casts

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, return code suggests integer, so I would use integers for this. If we have the ReturnCode type, it could implement Stringer interface. We can have a method: FormatError(code ReturnCode, err error) that returns code + ":" + err.Error(), and this can be our Error for GenericAPIResponse.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If I would set it to ReturnCode type, why would this help us? You can see the return code of each API call without the need to be included in the response payload. The idea of return code is that we can define custom return codes that can be customized in the future. For now, I only 'copied' the 200, 400 and 500 return codes.
@andreibancioiu can you please provide an input?

Copy link
Contributor

Choose a reason for hiding this comment

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

I was saying to use the ReturnCode type directly in the structure so you don’t have to do string(ReturnCode)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done. also, changed return codes messages to snake case

c.JSON(
http.StatusOK,
core.GenericAPIResponse{
Data: gin.H{"details": details},
Copy link
Contributor

Choose a reason for hiding this comment

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

A cleaner approach is to have this extra property wrap inside data, this way the response is verbose enough so you know what you are getting back.

shared.GenericAPIResponse{
Data: nil,
Error: errors.ErrInvalidAppContext.Error(),
Code: string(shared.ReturnCodeInternalError),
Copy link
Contributor

Choose a reason for hiding this comment

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

Also, return code suggests integer, so I would use integers for this. If we have the ReturnCode type, it could implement Stringer interface. We can have a method: FormatError(code ReturnCode, err error) that returns code + ":" + err.Error(), and this can be our Error for GenericAPIResponse.

bogdan-rosianu and others added 4 commits June 3, 2020 12:20
# Conflicts:
#	api/address/routes_test.go
#	api/transaction/routes.go
#	api/transaction/routes_test.go
iulianpascalau
iulianpascalau previously approved these changes Jun 4, 2020
iulianpascalau
iulianpascalau previously approved these changes Jun 4, 2020
ccorcoveanu
ccorcoveanu previously approved these changes Jun 5, 2020
@iulianpascalau iulianpascalau changed the base branch from development to release-candidate June 5, 2020 12:13
@iulianpascalau iulianpascalau dismissed stale reviews from ccorcoveanu and themself June 5, 2020 12:13

The base branch was changed.

iulianpascalau
iulianpascalau previously approved these changes Jun 5, 2020
ccorcoveanu
ccorcoveanu previously approved these changes Jun 5, 2020
@bogdan-rosianu bogdan-rosianu changed the base branch from release-candidate to development June 9, 2020 07:50
@bogdan-rosianu bogdan-rosianu dismissed stale reviews from ccorcoveanu and iulianpascalau June 9, 2020 07:50

The base branch was changed.

iulianpascalau
iulianpascalau previously approved these changes Jun 9, 2020
ccorcoveanu
ccorcoveanu previously approved these changes Jun 11, 2020
@@ -279,10 +272,10 @@ func PeerInfo(c *gin.Context) {
if !ok {
c.JSON(
http.StatusInternalServerError,
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe remove the struct from routes_test.go? The one with the TODO, also the TODO on L352 should be fixed. Thanks.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

Copy link
Contributor

@LucianMincu LucianMincu left a comment

Choose a reason for hiding this comment

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

System tests passed.

@LucianMincu LucianMincu merged commit 5dd1eaa into development Jul 2, 2020
@LucianMincu LucianMincu deleted the generic-api-reponses branch July 2, 2020 14:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:feature New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants