octokit.net/Octokit/Models

Octokit Models

These either represent the body of a GitHub API request or response.

Request objects should be placed in the, you guessed it, Request folder. Likewise Response objects should be placed in the Response folder.

Some models can be used for both requests and responses.

Request models

The general design principle for request models are:

1. They represent the body of a request.
2. Properties that are required by the API should be required by the model and passed in via the constructor.
3. Required properties should not have a setter since they will be set by the constructor.
4. All other properties should have both a getter and setter.

Note that Octokit.net automatically converts property name to the Ruby casing required by the GitHub API. Thus a property named BreakingBad would be passed as breaking_bad.

Response models

The general design principle for response models are:

1. They should be immutable. As such, properties have a public getter and protected setter.
2. We want the properties to be read only, but also make it possible to mock the response from API methods.
3. They must be easily serialized and deserialized.
4. They need a default constructor as well as one that takes in every parameter.

We're in the process of reconsidering this design as it's created a few problems for us. Namely that creating these objects in a unit test is a royal pain.

Notes

There's a lot of confusion caused by the fact that the GitHub API returns GitHub resources as well as Git resources. For example, you can use the Git Data API to directly manipulate Git objects such as a commit. At the same time, GitHub also has its own commit (represented by GitHubCommit in Octokit.net) that contains the GitHub information around the commit such as comments.