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.

18 votes

Adam Brown shared this idea · Feb 9, 2015 · Report… · Admin →

Closed ·

AdminDevin Lampe (Technical Experience Manager, The Mountaineers) responded · Jul 9, 2024

Changing from DECLINED to CLOSED to follow the improved and streamlined feedback status options: https://www.mountaineers.org/blog/new-technology-experience-manager-feedback-management-improvements

Show previous admin responses (5)

Kristina Ciari Tursi responded · Mar 28, 2024

We receive a lot of offers from IT folks offering to help, particularly folks with development experience. While we appreciate it, our website is not terribly complicated but is incredibly specific to our organization. To effectively play in that space, someone needs to be both a master of our technology stack AND have a detailed and nuanced understanding of the interplay between volunteer needs, user behaviors, and how the backend systems sync and impact each other.

For that reason, we have chosen to hire staff to run our IT needs even though we have volunteers who could do it, just as we have chosen to hire a CEO even though we have volunteers with executive leadership experience.

We also discussed the idea of giving a technology committee access to our GitHub and developers to support development, or find another way to get volunteers involved “since their time is free”. And we have learned that we don’t have staff capacity to manage a larger team of volunteers for this. We did try this approach in the beginning (2014 when we launched with a technology committee). But, as sometimes happens with committees, it was not ultimately successful and was disbanded by the committee’s choice.

At this point, we do not see a path forward where any of our technology will be volunteer-owned, particularly something like an app that we would have no control over and would ultimately be held accountable for if something were to go wrong. For that reason we’re declining this idea, even though it’s a generous and good one.

Proposed ·

Jeff Bowman responded · Mar 20, 2018

Our Technology Advisory Committee has reviewed this topic. It is low priority because of the mobile responsive theme that we developed for our website and the concerns outlined by Eric in the comments on this idea.

Proposed ·

Jeff Bowman responded · May 9, 2017

Jeff Bowman responded · Jul 2, 2015

Our Technology Advisory Committee is reviewing this topic.

New ·

Jeff Bowman responded · Feb 26, 2015

Comments are closed

An error occurred while saving the comment

Rachel Hessler commented · September 3, 2023 4:49 PM · Report

Allow members to access The Mountaineers website off of a browser, and instead on a mobile app. The app could have additional features added to it in the feature, but at present it could perform just the same as the website.

Submitting...
Michael Westbrook commented · July 8, 2023 7:14 PM · Report

Hello, I just wanted to check in on this old topic. Has there been any more thought on this? I know this is no easy task and I would be willing to volunteer my professional services as a software engineer to at least do a feasibility analysis. I run the Foothills Wilderness Navigation course and a lot of my work is highly repetitive. Being able programmatically manage large rosters and post courses with many activities would be amazing!

Submitting...
Yarian Gomez commented · April 7, 2016 7:33 PM · Report

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.

Submitting...
Yarian Gomez commented · April 7, 2016 7:32 PM · Report

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.

Submitting...
AdminEric Linxweiler (Admin, The Mountaineers) commented · September 2, 2015 4:24 PM · Report

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

Submitting...
[Deleted User] commented · August 30, 2015 12:15 PM · Report

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

Submitting...
AdminJeff Bowman (Associate Director of Information Technology, The Mountaineers) commented · August 26, 2015 8:39 AM · Report

Joe,

You might also want to add similar comments to these two ideas:

Improve Trip Reports - https://mountaineers.uservoice.com/forums/273688-general-feedback/suggestions/6763358-improve-trip-reports-sd22

Activity and Routes & Places Map Search - https://mountaineers.uservoice.com/forums/273688-general-feedback/suggestions/6732775-add-activities-and-routes-places-to-a-map-sd184

Jeff

Submitting...
Joe Osowski commented · August 24, 2015 10:22 PM · Report

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

Submitting...
Dennis Miller commented · February 11, 2015 10:37 AM · Report

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.

Submitting...