Share your idea...

Publicly accessible API

As a member of the Mountaineers, I'd love to give back in a way that I have particular expertise.

It would be great of the website had a public facing REST API for exposing data such as events and classes.

At least in a read capacity. My particular goal would be to write an Android (and possibly iOS) app to browse the events and what not.

It would be great to have easy native access to my up coming events, and be able to launch navigation to the event right from the app.

I have extensive experience writing and working with REST APIs and consuming them via mobile clients.

29 votes
Vote
Sign in
Signed in as (Sign out)
You have left! (?) (thinking…)
Adam Brown shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

7 comments

Sign in
Signed in as (Sign out)
Submitting...
  • Yarian Gomez commented  ·   ·  Flag as inappropriate

    I don't see a way to edit a comment but I wanted to add that Adam, if the API gets created shoot me a message, would love to help with the app. I also have experience with Android and came here to ask for something similar.

  • Yarian Gomez commented  ·   ·  Flag as inappropriate

    Hey Eric,

    Not sure if this is still an ongoing interest, but had some thoughts:

    - Are these third party contributions, or are they something different?

    Different. It's more about exposing an API that serves up certain data and then letting developers use that data to build cool things with it.

    - How do we safeguard Mountaineers information, such as private member information?

    It's up to you what you expose. I would suggest going simple at first and only publishing public info (like the class schedule, and maybe how many slots are open). Once you feel comfortable with that up and running and solve the challenges that come with it you can figure out authentication and private information with things like OAuth.

    - How do we support things that look and feel like Mountaineers apps (i.e. when people send a ticket in for an app built by someone else)?
    Might make sense to read the answer below. But basically, you put it in the terms and conditions that mimicking the branding of the Mountaineers is not allowed and that you offer API access at your discretion. As for tickets for external apps, I had this problem at a previous job and it wasn't that bad. It's a bit annoying but we basically said "Sorry, we are not the developers of that app, please contact them at ...@....com" and that was that.

    - How do we say yes? When do we say no?
    Typically you set up the API to require a developer key on every request. You are the sourcing authority for developer keys, so you can make the registration process ask for information such as how the API will be used, and you can layo out what the terms and conditions are. You can also use this to track usage per key so you can figure out if someone is abusing the API and block them if necessary.

    - Do we need to have a set of expectations for developers? NDAs?

    Mostly just terms and conditions of how your API may or may not be used. An example of one can be found here:
    http://www.brewerydb.com/developers/docs-terms

    - How can we enforce quality control? Do we need to?

    Not sure I have an answer because it's a tough question. I don't think you need to, unless the application claims affiliation with the Mountaineers (which you should put in your terms of condition under the You Shall Not category). Problems that could come of it include potential damage to your brand and the customer service for other apps issue, but I think you gain more than you lose by not trying to control it tightly.

    - How do we not break what we have?
    It's impossible for me to answer this question. It depends how scalable your current technology stack is. One thing you can do is do "load testing" where you hit your internal APIs with multiples of the requests you currently get (i.e. what happens if I hit my server with 5x the peak traffic I normally get) and seeing what happens. If you do this at night when not many people are using the site it minimizes impact.

    There's more to not breaking what you have than just load though, in exposing the data in the first place you may have to make changes to how your data systems work to make it more friendly to outside developers, which introduces risk in bugs. Again, I think it's still worth it, but it is important to consider if you have the team to do any changes needed at the moment.

    - What policies do we need in place to make this work?”

    Not sure what this means.

    Hope that helps, would love to see an API for Mountaineers data out there.

  • Eric Linxweiler commented  ·   ·  Flag as inappropriate

    This is an awesome idea! As the chair of our Tech Advisory Cmte, it's a question we're actively trying to allow for. With the broad level of expertise and interest in doing so, the question is "how".

    However, that poses lots of questions, such as:
    - Are these third party contributions, or are they something different?
    - How do we safeguard Mountaineers information, such as private member information?
    - How do we support things that look and feel like Mountaineers apps (i.e. when people send a ticket in for an app built by someone else)?
    - How do we say yes? When do we say no?
    - Do we need to have a set of expectations for developers? NDAs?
    - How can we enforce quality control? Do we need to?
    - How do we not break what we have?
    - What policies do we need in place to make this work?”

    If any of you who like this idea are willing to help us determine what approaches we can take, please contact me directly. We really want to support this!

    Thanks,
    Eric Linxweiler

  • Cheryl Talbert commented  ·   ·  Flag as inappropriate

    It sounds like Adam might be a great expert among our volunteers to help with the development of our mobile functionality!!

  • AdminJeff Bowman (IT Manager, The Mountaineers) commented  ·   ·  Flag as inappropriate
  • Joe Osowski commented  ·   ·  Flag as inappropriate

    A++ It would be great for trip reports to. If there was a way to search for trip reports (via API) by date and lat/long, it would be amazing

  • Dennis Miller commented  ·   ·  Flag as inappropriate

    I fully support this idea and would like to add that our branch and committee websites could be made more functional if we could "pull" info from the club website through a published API. As it stands, we can only do it by "screen scraping" html responses which is a horrible proposition for our volunteer webmasters.

General Feedback: Members

Feedback and Knowledge Base