You know about slack-api-ref?

[dblock]

Is https://github.com/slack-ruby/slack-api-ref the same? More complete?

[mthjones]

Interesting, thanks for the heads up! I wasn't aware of that project.

One issue I noticed in those schemas is a lack of response or object schemas, which are very important for this project to generate deserializable response types.

Perhaps we can coordinate our efforts to allow the schemas to work for both of us.

[dblock]

I'd take any PRs into slack-api-ref that make sense. That project is used by https://github.com/slack-ruby/slack-ruby-client and possibly others so it's not going away.

[mre]

slack-api-ref is auto-updated by a cronjob whenever there are changes on the API. Also it contains all example responses from the API.

@mthjones maybe you could contribute your schema for the responses to slack-api-ref. It would greatly help to have it all in one place.

Also, did you write the schemas yourself or did you use a tool for that? Can't find any code for that in the project. Would be great to add it to the repo. 😃

[mre]

Any update on this? Would really love to hear, which tool you use to generate the slack-api-ref.

[mthjones]

@mre Put up the scraper that generates the schemas (it's pretty horrific).

I don't have any time to dedicate to looking at merging the two schema definitions. Happy to take PRs on slack-rs-api that use the slack-ruby schemas though if anyone is interested.

[Mange]

I looked into those schemas, and it's just like was said: It contains no information about the actual content of messages.

The Ruby client does not even try to emit the fields that are possible, instead dynamically typed "object/hash" mashups are used, where x.foo would look for a "foo" key in the underlying storage. That's how they get away with this.

I raised a question for the official Swagger docs repo from Slack here slackapi/slack-api-specs#7. It might be our best bet...