Should we provide API to APIOps events related information?

API economy community without APIs to community meetup events and related information is not acceptable. Everyone should have access to information about meetups regardless of location. You can be in Finland, Sweden, US, or Vietnam — you should be able to find our meetups and participate online (via Youtube) if you can not physically participate our API economy tech talks.

Happy APIOps youngsters in Asia want to know too when meetups are held and how to participate online.

Situation is not that bad even with current solutions provided by platforms used. Right now you can get:

In other words, data streams exists but not in a way that information is super simple to utilize by consumers. The solution might be multiple APIs, but possibly we can get it all in one. That might be more convenient for the consumers. Offering easy way to consume APIOps events related information, help growing our community.

Nevertheless, question is: Does aggregated API bring enough added value for consumers? Let’s assume it does. Some questions remain: What kind of API should we provide? What would be the information included to the API?

Meetups related information — some requirements

APIOps activity is based on meetups coordinated with around the world (see current local groups). Thus we need collected information about the meetups and information related to the meetups.

The API should provide at least:

  • Future meetups (date, title, description, city, RSVP count, id( and web url)
  • List of past events (date, title, description, city, RSVP count, id( and web url)
  • Information about future live APIOps Youtube streams (date, title, description, id(youtube) and web url)
  • Information about APIOps Youtube channel (information about recordings available)

Poll was executed before going forward

Before going forward with the implementation, we did a poll in Twitter: “Would you like to have feed for future #APIOps meetups? Which kind of feed?” with options “REST (JSON), GraphQL, RSS and other”.

The same question was posted to Facebook group as well. In addition the same poll was casted in all APIOps sites. Most of the respondents want to have REST API. Some voted for GraphQL and RSS as well.

Assumed use cases

To make an educated guess on what information API should provide, we need to define some use cases for the API. Based on those we can build version 1 API.

  • APIOps events information needs to be added to other aggregated event calendars. For this developer needs easy access to future and past events. Information should include: Title, date and time, youtube stream if available, description, physical meetup location address, link to for RSVP and logo URL. Getting just future meetups from API must be possible.
  • APIOps community needs one pager in which all events are listed. In the page user must be able to filter events by cities and dates. In addition there should be link to for RSVP and to join local group. Each group has own logo which is displayed at the listing. Live youtube stream address should be also shown.
  • In past events listing we should be able to show links to recordings from previous meetups. List of recordings should have title, description, date. The listing could be list of embedded Youtube videos. List should show last five recordings and link which directs user to APIOPs youtube channel which contains list of all recordings.

Standard Linked Events API

In the smart city context cities have been pushing standard REST API format for events. OpenAPI spec for the API is in Github and it is used by some cities. It might make sense to use that in this too. Eventhough all our feature requests are not supported by standard Linked Events API, we can extend it if needed. API must have publicly available OpenAPI spec in Github. Source code must be open source too and be available in Github under APIOps organisation.