(→Interested in our Open311 Efforts) |
(→Proposed Architecture) |
||
| Line 23: | Line 23: | ||
=== Proposed Architecture === | === Proposed Architecture === | ||
[[File:architecture_diagramv1.jpg]] | [[File:architecture_diagramv1.jpg]] | ||
| + | |||
| + | === <h2>SF Open 311 API</h2> === | ||
| + | <h2>Description</h2> | ||
| + | Open311 will make public APIs for developers to build applications to report issues such as graffiti, potholes, and street cleaning directly to city departments. | ||
| + | <h2>Open311 API documentation</h2> | ||
| + | Here is a draft of the Open311 APIs we are working on. These are subject to change based on input from others and ideas generated at the <a title="OPen 311 Dev Camp Wiki" href="http://wiki.open311.org/Open311DevCamp" target="_blank">Open 311 Dev Camp</a> held October 24, 2009. | ||
| + | <h3>Service Lifecycle</h3> | ||
| + | The following describes the user experience for submitting a 311 service request: | ||
| + | |||
| + | Service Request >> Select Location >> Service Details>> Citizen Information (optional): >> Service Request # and Service Level Agreement >> Status Update | ||
| + | <h3>Select Service</h3> | ||
| + | <ul><strong>Purpose:</strong> provide a list of acceptable 311 services and associated service code | ||
| + | <strong>Method name:</strong> service_list | ||
| + | <strong>URL:</strong> | ||
| + | <strong>Formats: </strong>xml, json, rss, atom | ||
| + | <strong>HTTP Method: </strong>GET | ||
| + | <strong>Requires Authentication: </strong>false | ||
| + | <strong>Arguments: </strong>none | ||
| + | <strong>Response:</strong> <ul> | ||
| + | <li>service_name</li> | ||
| + | <li>service_code</li></ul> | ||
| + | </ul> | ||
| + | <strong> | ||
| + | <h3>Create Request</h3> </strong> | ||
| + | <ul><strong>Purpose:</strong> Create services | ||
| + | <strong>Method name:</strong> services | ||
| + | <strong>URL:</strong> | ||
| + | <strong>Formats:</strong> xml, json, rss, atom | ||
| + | <strong>HTTP Method:</strong> GET | ||
| + | <strong>Requires Authentication:</strong> true | ||
| + | <strong>Arguments:</strong> | ||
| + | <ul> | ||
| + | <li>service_code (obtained from method service_list)</li> | ||
| + | <li>lat <a href="http://en.wikipedia.org/wiki/World_Geodetic_System">(WGS84)</a></li> | ||
| + | <li>long <a href="http://en.wikipedia.org/wiki/World_Geodetic_System">(WGS84)</a></li> | ||
| + | <li>customer_email</li> | ||
| + | <li>first_name (optional)</li> | ||
| + | <li>last_name (optional)</li> | ||
| + | <li>phone_number (optional)</li> | ||
| + | <li>description (free form limited to 4,000 characters)</li> | ||
| + | <li>photo_url (location of photo(s))</li> | ||
| + | </ul> | ||
| + | <strong>Response: </strong> | ||
| + | <ul><li>service_request_id</li> | ||
| + | <li>service_level_agreement</li> | ||
| + | <li>error codes</li> | ||
| + | </ul></ul> | ||
| + | <h3>Status Update</h3> | ||
| + | <ul><strong>Purpose:</strong> provide a status update for service request | ||
| + | <strong>Method name:</strong> status_update | ||
| + | <strong>URL:</strong> | ||
| + | <strong>Formats: </strong>xml, json, rss, atom | ||
| + | <strong>HTTP Method: </strong>GET | ||
| + | <strong>Requires Authentication: </strong>false | ||
| + | <strong>Arguments: </strong> | ||
| + | <ul><li>service_request_id</li></ul> | ||
| + | <strong>Response:</strong> | ||
| + | <ul><li>status</li> | ||
| + | <li>title</li></ul> | ||
| + | </ul> | ||
This was taken from the Notes from Cities portion of the Open311 DevCamp Etherpad
311 twitter integration, exciting about participating in Open311 api, been considering for a while. Agrees with not just looking at request, but also disseminating information. Happy to focus just on requests for now, but then getting to how to answer questsion. Draft api is modeled after DC api. Fast tracking this, next few months . Using Lagan system, the vision is to route that to departments that do the work. Have a middleware system, using Oracle, thinking of changing that model, so 311 is a central hub, so other depts poll system. rather than pushing data out, just wnt to make sure that information will flow out. Very optimistic
Information on San Francisco's Open311 implementation
We’d like to invite anyone interested in moving the Open311 API forward to this public meeting. So we have an idea of your areas of interest and some background we ask that you fill out a simple form.
Here are the details: When: Dec 3rd, 5:30PM PST Where: 641.715.3625 Pin: 813951#
Agenda: 1. Present to the public our draft design spec 2. Identify gaps in design 3. Brainstorm
Open311 will make public APIs for developers to build applications to report issues such as graffiti, potholes, and street cleaning directly to city departments.
Here is a draft of the Open311 APIs we are working on. These are subject to change based on input from others and ideas generated at the <a title="OPen 311 Dev Camp Wiki" href="http://wiki.open311.org/Open311DevCamp" target="_blank">Open 311 Dev Camp</a> held October 24, 2009.
The following describes the user experience for submitting a 311 service request:
Service Request >> Select Location >> Service Details>> Citizen Information (optional): >> Service Request # and Service Level Agreement >> Status Update
Response:
Response: