API for the Russian public initiative. Step 2.2: US experience with electronic petition data - White House API
Earlier, I wrote in a couple of posts about how the openness of electronic petitions in different countries is arranged, what data there is in Russia and how APO can be made for the well-known Russian public initiative - www.roi.ru.
Read all this here:
This time we will look at how the electronic petitions of the White House are arranged, primarily from the point of view of their openness and suitability for data to be used.
')
The figures take into account only those petitions that passed the 1st threshold of 150 signatures in 30 days.
One of the important differences between the White House of the United States and the sites of all the leaders in the world is the focus on developers. The site even has a special section / Developers where data is posted, the source code of projects is disclosed, and the API of many of the initiatives, if not all, are described.
Since we are primarily interested in petitions, we consider them in more detail.
Firstly, the source code of the petitions is fully published on Github - https://github.com/WhiteHouse/petitions
The repository has more than 15 contributors , dozens of bugs and questions, and we can say that the project is being developed in an open way.
The other side of what is happening in that for developers is available not only the source code, but also the API and data accumulated on the service.
All APIs on petitions are available via the link - https://petitions.whitehouse.gov/developers
The data access API consists of 3 endpoints:
Returns a list of petitions, individual petitions and signatures to individual petitions. Does not support non-Latin characters and contains a limit of no more than 10 requests per second.
The API description includes filtering by: link, status, number of signatories and much more.
Learn more - petitions.whitehouse.gov/developers#petitions-index
Returns a detailed description of a particular petition including the date of its creation, name, text, status, deadline, topics, number of signatories.
Learn more - petitions.whitehouse.gov/developers#petitions-retrieve
And, finally, for each petition, it is possible to get a list of all, or a sample of the filters that signed the petition without their full name, but with a geocode in the form of a zip code and the exact date and time of the signature.
Here is the signature array element when responding to this method:
Learn more - petitions.whitehouse.gov/developers#petitions-signatures
The latter is particularly interesting - the ability to obtain information on each voice gives a lot - quite a few developers in the US use this to monitor the activity of petition signatures.
But that's not all. For those who are not so important to receive data in real time, but it is important to have a base for analysis, the developers provide data for mass upload. Follow the link https://api.whitehouse.gov/v1/downloads/data.sql.zip
Adamp file in SQL for 200 megabytes.
This is about the fact that when there is a desire to make something open, it’s not reservations about how difficult it is, but quickly done in at least that simple way.
All of the above would not be so interesting if the example of the opening of data on petitions in the White House would not appear many projects using this information. The project was originally made by developers for developers very quickly became popular with those who created the ecosystem around.
The White House itself has a section called API Gallery where I counted at least 18 apps.
Here is a partial list:
Petitions are, although important, far from the only thing that the state should open for everyone. The API for petitions is only a small part of all APIs by open US departments over the past few years. Here you can see much more than anything else - gsa.imtqy.com/slash-developer-pages , and activists have long been creating the project / the united states collecting key APIs in one place
As an afterword. The main difference between the US experience in working with petitions is the deliberate technological transparency and the construction of an ecosystem. Cooperation with independent developers allows us to attract much more attention to petitions and use technical tools to promote initiatives.
Read all this here:
- API for the Russian public initiative. Step 1: data collection and analysis
- API for the Russian public initiative. Step 2.1: UK experience with electronic petition data
This time we will look at how the electronic petitions of the White House are arranged, primarily from the point of view of their openness and suitability for data to be used.
')
reference
Peculiarities of petitions in the USA
- They relate precisely to the president and his administration gives the answers.
- They do not require anything other than email to sign - additional authorization is unnecessary.
- Petitions must pass 2 thresholds - 150 signatures in 30 days so that they can be found (they are available through a direct link) and 100,000 signatures in 30 days to get an official response - petitions.whitehouse.gov/how-why/terms-participation
In numbers
- only 2246 petitions
- answered 208 petitions
- waiting for a response 26 petitions
- 1972 petitions closed
- open for voting 40 petitions
The figures take into account only those petitions that passed the 1st threshold of 150 signatures in 30 days.
WhiteHouse.gov/developers
One of the important differences between the White House of the United States and the sites of all the leaders in the world is the focus on developers. The site even has a special section / Developers where data is posted, the source code of projects is disclosed, and the API of many of the initiatives, if not all, are described.
Open source code
Since we are primarily interested in petitions, we consider them in more detail.
Firstly, the source code of the petitions is fully published on Github - https://github.com/WhiteHouse/petitions
The repository has more than 15 contributors , dozens of bugs and questions, and we can say that the project is being developed in an open way.
Open API
The other side of what is happening in that for developers is available not only the source code, but also the API and data accumulated on the service.
All APIs on petitions are available via the link - https://petitions.whitehouse.gov/developers
The data access API consists of 3 endpoints:
- GET / v1 / petitions
- GET / v1 / petitions / {petition_id}
- GET / v1 / petitions / {petition_id} / signatures
List of petitions and sample petitions (GET / v1 / petitions)
Returns a list of petitions, individual petitions and signatures to individual petitions. Does not support non-Latin characters and contains a limit of no more than 10 requests per second.
The API description includes filtering by: link, status, number of signatories and much more.
Learn more - petitions.whitehouse.gov/developers#petitions-index
Petition Card (GET / v1 / {petition_id})
Returns a detailed description of a particular petition including the date of its creation, name, text, status, deadline, topics, number of signatories.
Learn more - petitions.whitehouse.gov/developers#petitions-retrieve
List of signatories (GET / v1 / {petition_id} / signatures)
And, finally, for each petition, it is possible to get a list of all, or a sample of the filters that signed the petition without their full name, but with a geocode in the form of a zip code and the exact date and time of the signature.
Here is the signature array element when responding to this method:
"0": { "id": "5017a5ca6889385944000000", "type": "signature", "name": "DP", "zip": "94530", "created": 1343727050 }, Learn more - petitions.whitehouse.gov/developers#petitions-signatures
The latter is particularly interesting - the ability to obtain information on each voice gives a lot - quite a few developers in the US use this to monitor the activity of petition signatures.
Open data
But that's not all. For those who are not so important to receive data in real time, but it is important to have a base for analysis, the developers provide data for mass upload. Follow the link https://api.whitehouse.gov/v1/downloads/data.sql.zip
Adamp file in SQL for 200 megabytes.
This is about the fact that when there is a desire to make something open, it’s not reservations about how difficult it is, but quickly done in at least that simple way.
Ecosystem
All of the above would not be so interesting if the example of the opening of data on petitions in the White House would not appear many projects using this information. The project was originally made by developers for developers very quickly became popular with those who created the ecosystem around.
The White House itself has a section called API Gallery where I counted at least 18 apps.
Here is a partial list:
- Wordpress Plugin - wordpress.org/plugins/we-the-people
- IPhone App - itunes.apple.com/us/app/wethepeople-petitions/id627813134?ls=1&mt=8
- Petition Kicker, Petition Probability Monitor - petitionkicker.herokuapp.com
- Instant Petition Search - ivan.io/wethepeople-instantsearch
- News and Petition Relationship Monitor - github.com/bryanbraun/petitions-newslink and newslink.herokuapp.com
Petitions are not all
Petitions are, although important, far from the only thing that the state should open for everyone. The API for petitions is only a small part of all APIs by open US departments over the past few years. Here you can see much more than anything else - gsa.imtqy.com/slash-developer-pages , and activists have long been creating the project / the united states collecting key APIs in one place
As an afterword. The main difference between the US experience in working with petitions is the deliberate technological transparency and the construction of an ecosystem. Cooperation with independent developers allows us to attract much more attention to petitions and use technical tools to promote initiatives.
Source: https://habr.com/ru/post/201376/
All Articles