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

Create api types package for structured responses #10986

Merged
merged 2 commits into from Mar 2, 2015

Conversation

crosbymichael
Copy link
Contributor

This creates a new package api/types and also implements a new type for the /containers/create endpoint which is also consumed via the client.

Move the stats structs from the api/stats package into a new package
api/types that will contain all the api structs for docker's api request
and responses.

Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
var result engine.Env
if err := result.Decode(stream); err != nil {
var response *types.ContainerCreateResponse
if err := json.NewDecoder(stream).Decode(&response); err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

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

You use double pointer tactic here, but not checking for nilness. Looks like potential panic.

@crosbymichael
Copy link
Contributor Author

ping @jfrazelle @tiborvass @LK4D4

// creation of a new container.
type ContainerCreateResponse struct {
// ID is the id of the created container.
ID string `json:"Id"`
Copy link
Contributor

Choose a reason for hiding this comment

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

Why we need such tag? I vote for using default tags, it is simpler.

Copy link
Contributor

Choose a reason for hiding this comment

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

+1, it's case insensitive by default: http://play.golang.org/p/jhQA8kZpXr

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Explicit is better than implicit especially when we want to enforce API consistency and make sure that the tags don't change the responses. With the tag i know that for a 100% fact I will get the marshaled response that I want.

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, you should be sure by test, not by some string, which also easy to misspell. We had such "100% fact" already in devicemapper code with json: "Id".
But I'm okay if you want save them.

This type is produced on the server side and is a type safe struct that
can be encoded to json.  It is consumed via the client.

Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
@jessfraz
Copy link
Contributor

COOL!

@tiborvass
Copy link
Contributor

LGTM

1 similar comment
@estesp
Copy link
Contributor

estesp commented Feb 26, 2015

LGTM

@thaJeztah
Copy link
Member

If I understand correctly, this allows defining standardized responses for API calls. Would this be usable for outputing more meaningful messages, such as requested in #7761, #11016, #9120 and #9315?

(might be on the wrong foot here 😄)

jessfraz pushed a commit that referenced this pull request Mar 2, 2015
Create api types package for structured responses
@jessfraz jessfraz merged commit 2bfa701 into moby:master Mar 2, 2015
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.

None yet

8 participants