Views
Difference between revisions of "San Francisco"
Collaboration for an Open311 Standard
(→SF Open 311 API) |
(→SF Open 311 API) |
||
| Line 71: | Line 71: | ||
</ul> | </ul> | ||
<strong>Response: </strong> | <strong>Response: </strong> | ||
| − | <ul> | + | <ul><li>service_request_id</li> |
| − | <li>service_request_id</li> | + | |
<li>service_level_agreement (may not be returned)</li> | <li>service_level_agreement (may not be returned)</li> | ||
<li>account_id (may not be returned)</li> | <li>account_id (may not be returned)</li> | ||
| Line 85: | Line 84: | ||
<strong>Requires Authentication: </strong>false<br> | <strong>Requires Authentication: </strong>false<br> | ||
<strong>Arguments: </strong> | <strong>Arguments: </strong> | ||
| − | <ul><li>service_request_id</li> | + | <ul><li>city_id</li> |
| + | <li>service_request_id</li> | ||
<li>client_id</li></ul> | <li>client_id</li></ul> | ||
<strong>Response:</strong> | <strong>Response:</strong> | ||
Revision as of 16:03, 8 January 2010
This page is a stub. If you have more content to add, please edit this page.
This was taken from the Notes from Cities portion of the Open311 DevCamp Etherpad
Contents
General Description
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
Interested in our Open311 Efforts
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
Proposed Architecture
SF Open 311 API
Description
Open311 will make public APIs for developers to build applications to report issues such as graffiti, potholes, and street cleaning directly to city departments.
Service Lifecycle
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
Select Service
- Purpose: provide a list of acceptable 311 services and associated service code
- service_name
- service_code
- service_description
Method name: service_list
URL:
Formats: xml
HTTP Method: GET
Requires Authentication: false
Arguments: city_id
Response:
list with the following:
Create Request
- Purpose: Create services
- city_id
- service_code (obtained from method service_list)
- client_id (unique id to client - username)
- lat (WGS84)
- lon (WGS84)
- address_string (text description of location)
- customer_email (optional)
- device_id (optional)
- account_id (optional)
- first_name (optional)
- last_name (optional)
- phone_number (optional)
- description (free form limited to 4,000 characters) (optional)
- media_url (location of media(optional)
- service_request_id
- service_level_agreement (may not be returned)
- account_id (may not be returned)
- error codes
Method name: services
URL:
Formats: xml
HTTP Method: POST
Requires Authentication: true
Arguments:
Response:
Status Update
- Purpose: provide a status update for service request
- city_id
- service_request_id
- client_id
- service_request_id
- status
- status_notes (may not be returned)
- service_name
Method name: status_update
URL:
Formats: xml
HTTP Method: GET
Requires Authentication: false
Arguments:
Response:
