ymtszw/hipchat_swagger

[DISCONTINUED] HipChat API specifications in Swagger YAML

⚠️ DISCONTINUATION NOTICE

HipChat itself is discontinued by Atlassian due to their partnership with Slack.

This Swagger specification file is therefore no longer maintained, and goes archive. Thanks for your interest, though! ❤️

hipchat_swagger

HipChat API specifications written in Swagger YAML.

Using Swagger (currently OpenAPI) specification 2.0.

Status

Currently in development. Gradually hand-exported from official HipChat API documentations.

APIs other than extension related ones are mostly included already.

My intention is to use this Swagger interpreted API specs to generate HipChat client library for languages I am using (especially Elixir).

Mostly I am constructing API spec YAML using online Swagger Editor.

Policy

• Meant to be used in generating client libraries.
  • Some strings are slightly altered for easier programmatic manipulations, like camelize or underscore.
  • e.g. "OAuth" -> "Oauth"
• Cover APIs used in server side only.
• Not all of API aspects are covered. Especially, many schema information are purposefully omitted.
  • Simply lacking efforts on my side. HipChat API docs are large and fine-grained.
  • Some APIs are omitted for simplified code generation; e.g. APIs requiring specific content-types.
  • Intending to rely on HipChat cloud/server's request validations, so that always latest and accurate validations can be applied.
    • If we try to apply client-side validations, we have to be very accurate about it, and must actively catch up on HipChat's API updates, which we cannot easily afford to.
• Always welcoming helps.

Usage

• As I mostly developing with online editor, files should be valid Swagger 2.0 specifications.
• You can just clone or submodule this repository, and import spec files for code generations, either using:
  • Swagger Codegen for your favorite languages and/or frameworks
  • Your own parser/code generator
    • Example: ymtszw/hipchat_elixir

Coverage

• Capabilities API
• Emoticons API
• Extensions API
• Groups API
• Integrations API
  • Get integration installable data API is omitted, since it is only used in installation flow, and the whole URL is sent to Add-on server upon installation. Just use that URL as-is, seems easier than extracting integration_id_or_key and token from it and supplying them to library function.
  • Invoke integration link API is omitted, since it is for client side use.
• Invites API
• Oauth Sessions API
• Prefs Public API (Included under Users API)
• Rooms API
  • Share file with room API is omitted, since it requires requests with multipart/related content-type.
  • Set topic API is omitted, since it requires (though undocumented,) application/json content-type.
• Users API
  • Share file with user API is omitted, since it requires requests with multipart/related content-type.

License

MIT