forked from octokit/octokit.net
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
extract OVERVIEW.md document which introduces the overall Octokit cod…
…ebase
- Loading branch information
Showing
2 changed files
with
34 additions
and
34 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,32 @@ | ||
### How is the codebase organised? | ||
|
||
The two main projects are the `Octokit` and `Octokit.Reactive` projects. | ||
|
||
The `Octokit.Reactive` library is a thin wrapper over the `Octokit` | ||
library - for those who want to use Reactive Extensions (Rx) instead of tasks. | ||
|
||
The namespaces are organised so that the relevant components are easy to discover: | ||
|
||
- **Authentication** - everything related to authenticating requests | ||
- **Clients** - the logic for interacting with various parts of the GitHub API | ||
- **Exceptions** - types which represent exceptional behaviour from the API | ||
- **Helpers** - assorted extensions and helpers to keep the code neat and tidy | ||
- **Http** - the internal networking components which Octokit requires | ||
- **Models** - types which represent request/response objects | ||
|
||
Unless you're modifying some core behaviour, the **Clients** and **Models** namespaces | ||
are likely to be the most interesting areas. | ||
|
||
The clients within a project are organized similarly to the endpoints in the | ||
[GitHub API documentation](http://developer.github.com/v3/) | ||
|
||
Some clients are "sub-clients". For example, when you navigate to the | ||
[Issues API](http://developer.github.com/v3/issues/) you'll notice there's an | ||
endpoint for issues. But in the right navbar, there are other APIs such as | ||
[Assignees](http://developer.github.com/v3/issues/assignees/) and | ||
[Milestones](http://developer.github.com/v3/issues/milestones/). | ||
|
||
We've tried to mirror this structure. So the `IObservableMilestoneClient` isn't | ||
a direct property of `IObservableGitHubClient`. Instead, it's a property of the | ||
`IObservableIssuesClient`. And thus you can get to it by going to | ||
`client.Issues.Milestones`. |