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

/learning response change #64

Open
sjsafranek opened this issue Apr 22, 2016 · 4 comments
Open

/learning response change #64

sjsafranek opened this issue Apr 22, 2016 · 4 comments
Labels

Comments

@sjsafranek
Copy link

it would be nice to get a json response from learning like the following
{
"message": "blah",
"details": {"name":"blah", "APS": 10, "user":"me!"},
"success": true
}

this would make it easier to read with programs utilizing the find system

@schollz
Copy link
Owner

schollz commented Apr 22, 2016

Whats "name"?
Also why do you need "user"? User should be given to the server, so the client will probably know about it.

@schollz schollz added the server label Apr 22, 2016
@sjsafranek
Copy link
Author

The Username is in the current message that is returned (it shouldn't be needed). Name is location name.

@schollz
Copy link
Owner

schollz commented Apr 22, 2016

Hmm. So the purpose of "message" is to relay the Debug message that the server itself into its own log. This is useful to me, as a developer, cause I can use a client to "see" the server Debug messages, since currently the App prints out the data['message'].

For practical functionality though - does the client need any of this? It already knows the username and the location and the number of APs. The client doesn't even have to output a 'message', it only does right now because its useful for my debugging purposes. Maybe the client only needs to respond to success (which should probably change to an HTTP status code).

@sjsafranek
Copy link
Author

The client probably doesn't need to see any of this. However I imagine for writing API tests it would easier to return the location name, and user within a more "machine" friendly message. If an incorrect user is returned this could highlight major async bugs that could potentially occur.

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