Note: should lat/long be one value? This makes it easier to add new query types. It might be like: point=100.1234%2035.1234 (i.e., space-separated), or just comma-separated (which doesn't need to be quoted).

Sure phil.ashlock.us 01:18, 31 December 2009 (UTC)

Note: should we accept a level of confidence, using the same scale as presented in the Google geocode API? A low confidence might mean we do a more fuzzy search.

Sure phil.ashlock.us 01:18, 31 December 2009 (UTC)

Note: should there be a kind of "id URL" in addition to this more explicit URL? For instance, if there are multiple APIs, they might each have a different "type" but still represent the same basic entity. These could all have the same id URI (e.g., http://sfgov/311) but still different specific endpoints

Unless this could just be derived from the URL, this is probably a good idea. If I understand correctly, you're suggesting like an identifier for the authority for the area/service-type? Maybe it could be referred to as "authority" or whatever, but something more descriptive than ID would probably be good. phil.ashlock.us 01:18, 31 December 2009 (UTC)

Note: should this be translated or translatable? E.g., {"en_US": "San Francisco 311 Information", "es": "San Fransisco 311 Informacion"} ?

Yes, we definitely want to leave room for at least a minimal level of translation for anything that would be human read. phil.ashlock.us 01:18, 31 December 2009 (UTC)

Note: would it make sense to inline GeoJSON?

Maybe. I'd be happy to defer deciding on this for now, if it makes testing easier by including it, please do. phil.ashlock.us 01:18, 31 December 2009 (UTC)

Note: should this return 404?

Note: are there any predictable errors? E.g., a lat/long that is impossible?

Maybe, but I don't think we need to worry about this yet. phil.ashlock.us 01:18, 31 December 2009 (UTC)

• [Edit↑]
• [History↑]