[seagrant-dev] Working Waterfronts API

Carr, Justin Justin.Carr at oregonstate.edu
Fri Jan 16 20:20:15 UTC 2015


Good questions! 

I went over the design specs that Mark and I talked about after Demo meeting #2 and I think the features that would require those endpoints are out of scope.

We would only need a general "Categories" or "Hazards" endpoint if we were going to filter our data by categories or hazards before showing it to the end user and no such filtering feature was asked for.

However, as was mentioned in IRC, I could see some very silly people wanting to browse the Oregon waterfront businesses by the kinds of hazards they present to life and limb.

-----Original Message-----
From: seagrant-dev [mailto:seagrant-dev-bounces at osuosl.org] On Behalf Of Evan Tschuy
Sent: Thursday, January 15, 2015 3:17 PM
To: seagrant-dev at osuosl.org
Subject: [seagrant-dev] Working Waterfronts API

Hi all,

I'm working on getting the Working Waterfronts API done, and I have some questions for you all on the mobile side of things, and for the other OSL developers.

Currently, in the draft API docs, we return a list of the categories a POI is a part of. Here's the relevant part of the docs:

    categories: [category1, category2, ...]

The categories will have an ID and a name. Should this be changed to something more like this:

    categories: [{'id': 1, 'name': 'category1'}, {'id': 2, 'name':
'category2'}, ...]


Additionally, the hazards are not exposed in the API documentation. At all.

I'm under the impression that they should be exposed much in the same way categories are above:

    hazards: [{'id': 1, 'name': 'hazard1'}, {'id': 2, 'name': 'hazard2'}, ...]

Thanks for any input any of you might have!

Evan Tschuy / tschuy
seagrant-dev mailing list
seagrant-dev at osuosl.org

More information about the seagrant-dev mailing list