*Gnip API v2.1 (https://demo-v21.gnip.com) *(doc rev 12) This document is divided into three sections: * Introduction to the Gnip Platform <#Introduction> o Before you can do anything you'll need an account. Get one here . * Overview of the Gnip Platform <#Overview> * Examples <#Examples> o Gnip Activities <#Examples_of_Activities> o Data Consumers <#Examples_for_Subscribers> o Publishers <#Examples_for_Publishers> * Gnip Platform Capabilities and Terminology <#Platform_Capabilities_and_Terminology> o Publisher and Filter Scoping o Activity Buckets o Convenience Libraries o Current list of Publishers o Gnip XML schema document * Introduction to the Gnip Platform* Gnip provides a set of services for accessing, filtering and integrating data from web APIs and feeds. To get started using the Gnip Platform first create an account. You can create one here in seconds. The Gnip Platform API is based on the REST approach (see Wikipedia for the explanation if you need one), and we provide convenience libraries for several popular languages (PHP, Java, .NET, Python, Perl and Ruby), so you can be up and running in the language or your choice in no time. The Gnip API version of this document is 2.1. At Gnip we use the hostname as the way to version the API, this means to access the 2.1 version of the Gnip API, you will need to use the host: *https://demo-v21.gnip.com* *. * There are two main data integration use cases supported by the Gnip Platform: Publishers & Data Consumers. Publishers represent sources of data available through Gnip Platform from different web APIs and feeds across the Internet, and Data Consumers, represent the developers and companies that use the Gnip Platform to access, filter and integrate social and business data into their applications. Developers have the choice of using the Gnip Developer Site or the Gnip Platform APIs to integrate data. The Gnip Platform APIs provides access to normalized *event* data. An *activity* contains all event meta-data and the data payload. The data payload represents the full raw data, from a data source (e.g, such Digg, Delicious, Twitter, Sixapart, etc). A *notification* is the subset of an *activity *and contains all the event meta-data, just no data payload. By providing these two options developers obtain the flexibility to request the type of data needed for their application and use case. Also, the data payloads included in an *activity* provide the raw, original, untouched (though encoded) event information from the data source that Gnip maps to the normalized Gnip XML. Gnip maps as much of the relevant raw data to the Gnip XML meta-data to assist Data Consumers so they do not need to proces the raw data payload at all. In order to protect the integrity of the Gnip XML, it is gzip'd and base64 encoded in the element. Data Consumers are responsible for decoding and un-gzip'ing the raw element if they need the original data (this can be easily done with the Gnip Convenience Libraries ). It is important to note that Data Consumers also have two options on how to receive data, either by a *subscription*, which represents the entire publisher "*firehose*" or by *filtering*, which represents specific views of a publisher data stream. Data Consumers can create filters <#Filter_terminology> for a specific publisher for either *notifications* or *activities*. * A *Firehose, *also sometimes called a *Public Timeline*, is the stream of all the activities from a given Publisher. (Note: not all Publishers support Public Timelines, and Public Timelines do not always contain full data.) To avoid Publisher name clashes and to show which publishers are 'bless and endorsed by Gnip", Publisher's are namespace scoped to either "gnip," "my," (private only to the Gnip account creator) or "public" (not supported at present). Public Timelines can be "polled" (HTTP GET) from Gnip. If you wish to have data pushed to you, you will need to create a *Filter*. * A *Filter* is a stream containing all the activities or notifications that meet a set of defined criteria, called *rules, *that are defined by the Data Consumer. For example, Filters allow Data Consumers to create data streams containing just the information from the Publisher based on users they are interested in (using Gnip *rule-type "actor"*), or all the data from Publisher "foo," that are tagged with a given string (using the Gnip *rule-type* *"tag"*). When a Data Consumer creates a Filter they are the only one who is granted access to use the filter. Filters can be "polled" (HTTP GET) from a Gnip generated end-point, or "pushed" (HTTP POST) to a Data Consumer POST URL endpoint that is defined in the Filter. In addition to the two approaches for defining data data consumption (see a Data Consumer example for more details <#Retrieve_recent_Activities_for_a_given_Publisher>), companies also can *publish* data into the Gnip Platform by mapping an existing data source to the Gnip XML schema. Here is an example of how to publish data <#Examples_for_Publishers> to the Gnip Platform. ------------------------------------------------------------------------ Overview of the Gnip Platform ------------------------------------------------------------------------ Gnip API Usage Information * Before you can do anything you will need an account. You can create one here in seconds. * All requests to Gnip must be made over HTTPS (HTTP over SSL/TLS). * The following examples assume you're sending HTTP BASIC AUTH'd requests to https://demo-v21.gnip.com * There are a variety of convenience libraries for many popular languages provided by Gnip to ease your integration. You can find them here. * The current list of Gnip Certified Publishers can be found here . * Gnip's XML schema can be found here . * Gnip Activity & Notification access o To access activities, use the "/*activity*/" endpoint. o To access notifications, use the "/*notification*/" endpoint. o Individual filters support only one endpoint type ("activity" or "notification"); not both. o You can not access the directly access the activity endpoint of a publisher for which you are not the owner *unless* you create a filter. Examples *Examples of Gnip Activities* The examples below are broken into Data Consumer and Publisher sections. Most users of Gnip are Data Consumers, but depending on the application, a user may be a Data Consumer, a Publisher, or both. Both Publishers and Data Consumers need to be familiar with Gnip activities which are individually represented by an document and collections of documents are wrapped in documents. Below are examples of each; the first example represents a "notification"-style activity that does not contain the activity's "full-data (payload)". Second is a "full-data" document example. Documents like these are emitted by both a Publisher's notification stream as well as a Filter's notification and activity streams. Sample of a Gnip Activity XML* for notifications (.../notification/...)* 2009-02-02T17:05:01.000Z post 0.33783490478 http://gnipherald.com/stories/0.33783490478/jousting-gone-bad.xml Vignette-Web-Publisher 38.2638886 -106.126131 Chloride Mine jvaleski http://gnipherald.com/stories/0.33783490478/jousting-gone-bad.html armor staff injury barinek http://apnewswire.com/jousting/accident.html *Sample of a Gnip Activity XML with full data enabled (.../activity/...)* 2009-02-02T17:16:01.000Z post 0.516958128858 http://gnipherald.com/stories/0.516958128858/jousting-gone-bad.xml Vignette-Web-Publisher 38.2638886 -106.126131 Chloride Mine jvaleski http://gnipherald.com/stories/0.516958128858/jousting-gone-bad.html armor staff injury barinek http://apnewswire.com/jousting/accident.html Jousting Event Went Awry Two drunken guys, two jousting sticks, blindfolds and running full bore down a hallway at each other, lead to a night in hospital for two university students. One with chest injury the other unharmed. REST of BODY http://images.gnipherald.com/jousting-thumbnail.jpg base64 encoded gzip compressed binary Examples for Data Consumers Retrieve recent Activities for a given Publisher This requires having a prior knowledge of the Publisher ID, a Publisher ID is usually just a commonly known name for the Publisher such as Publisher ID for twitter is "twitter". (A current list of Publisher IDs can be found here -- requires a Gnip account). In order to retrieve recent activities for a given Publisher (e.g. "*gnip-sample*"), construct a URL for the Publisher of interest and perform a HTTP GET to retrieve the |application/xml| representation of that activity stream; for details go here <#Activity_Buckets>. You can only access activities without full data, e.g. "notifications," for a Publisher's *Public* Timeline. If you want *full data*, you need to create a Filter and access it that way; for an example, go here <#Create_a_Filter_Example>. Publisher data is *namespaced*, that is, the list of publishers listed on the Gnip API site are scoped to "*gnip*". When you create a publisher, they will be scoped to "*my*". ===> GET /gnip/publishers/gnip-sample/notification/current.xml Accept: application/xml <--- 200 OK Content-Type: application/xml 2009-02-02T17:05:01.000Z post 0.33783490478 http://gnipherald.com/stories/0.33783490478/jousting-gone-bad.xml Vignette-Web-Publisher 38.2638886 -106.126131 Chloride Mine jvaleski http://gnipherald.com/stories/0.33783490478/jousting-gone-bad.html armor staff injury barinek http://apnewswire.com/jousting/accident.html Retrieve activity for a Publisher 'n' minutes ago (*up to 60 minutes in the past*) If you are interested in a point in the past, relative to now, you will need to determine what the difference is between you local clock and Gnip’s clock, to minimize clock drift as a variable in making requests for activities; for details go here <#Activity_Buckets>. ===> HEAD / <--- 200 OK Date: Mon, June 9 2008, 9:08:43 The returned |Date| header field can be used to figure the difference between Gnip's clock and the local one. Once that is known, the activity bucket ID for the time of interest can be calculated. Once the activity bucket ID is known its URL can be constructed using the same format as above, replacing "current" with an activity bucket ID (e.g.| *200806090910*)|, and the data can be retrieved. See the below section called "Activity Buckets <#Activity_Buckets>". The activity bucket ID is represented in *UTC time*. Please note that the two buckets, current and 0-1 minutes old contain a *variable* amount of data, that is, data will continue to be added to the buckets until a full minute has passed. Buckets that are from 1-2 minutes and older contain a *fixed* amount of data. |===> GET /gnip//publishers/gnip-sample/notification/*200806090910*.xml Accept: application/xml <--- 200 OK Content-Type: application/xml | 2009-02-02T17:05:01.000Z post 0.33783490478 http://gnipherald.com/stories/0.33783490478/jousting-gone-bad.xml Vignette-Web-Publisher 38.2638886 -106.126131 Chloride Mine jvaleski http://gnipherald.com/stories/0.33783490478/jousting-gone-bad.html armor staff injury barinek http://apnewswire.com/jousting/accident.html * Create a Filter and retrieve its Activity* To create a Filter you need one, or more, "*rules*." Each Publisher has a set of supported rule types which constrain the types of rules that can be specified for a Filter in a Publisher. For example, if a Publisher supports the rule types "Actor" and "To", a Filter can contain rules of using those types but cannot contain rules of type "RegardingURL", "Tag", and "Source". If a Filter is created with a rule type that a Publisher does not support, the server will return a response containing of an error message and error status code. Here is a list of Publishers. In order to find out what rule types a publisher supports you can look here . Send an HTTP POST request to create a Filter. For details go here <#Filters_Details>. |===> POST /gnip/publishers/gnip-sample/filters.xml Accept: application/xml Content-Type: application/xml jvaleski ajackson || <--- 200 OK Content-Type: application/xml Success| Once the Filter is created, accessing full-data activity associated with it is similar to accessing Publishers' notifications. Note that since fullData was specified as true in this example, the result will include the activity payload, and you'll access it via the ".../activity/..." URI. Trying to access the ".../notification/..." URI would generate a "Not Authorized" error. |===> GET /gnip/publishers/gnip-sample/filters/examplefilter/activity/current.xml Accept: application/xml <--- 200 OK Content-Type: application/xml | 2009-02-02T17:16:01.000Z post 0.516958128858 http://gnipherald.com/stories/0.516958128858/jousting-gone-bad.xml Vignette-Web-Publisher 38.2638886 -106.126131 Chloride Mine jvaleski http://gnipherald.com/stories/0.516958128858/jousting-gone-bad.html armor staff injury barinek http://apnewswire.com/jousting/accident.html Jousting Event Went Awry Two drunken guys, two jousting sticks, blindfolds and running full bore down a hallway at each other, lead to a night in hospital for two university students. One with chest injury the other unharmed. REST of BODY http://images.gnipherald.com/jousting-thumbnail.jpg base64 encoded gzip compressed binary Create a Filter and have its Activity POSTed to specified URL Create a Filter as in the previous example and in addition specify a postURL to which activities should be HTTP POSTed. Gnip validates the URL by making a HEAD request to it, so ensure that the postURL responds successfully to an HTTP HEAD request. For details go here <#Filters_Details>. |===> POST /gnip/publishers/gnip-sample/filters.xml Accept: application/xml Content-Type: application/xml http://mysite.example/inbound-activity-handler.cgi jvaleski ajackson || <--- 200 OK Content-Type: application/xml |Success Once the Filter is created, any activity that matches rules in the filter will be POSTed to the specified URL; see below for an example HTTP exchange that occurs when sending activities to a postURL. Gnip activity POSTing is currently fire-and-forget and does not interpret HTTP response codes from the POST. |===> POST http://mysite.example/inbound-activity-handler.cgi Content-Type: application/xml || 2009-02-02T17:16:01.000Z post 0.516958128858 http://gnipherald.com/stories/0.516958128858/jousting-gone-bad.xml Vignette-Web-Publisher 38.2638886 -106.126131 Chloride Mine jvaleski http://gnipherald.com/stories/0.516958128858/jousting-gone-bad.html armor staff injury barinek http://apnewswire.com/jousting/accident.html Jousting Event Went Awry Two drunken guys, two jousting sticks, blindfolds and running full bore down a hallway at each other, lead to a night in hospital for two university students. One with chest injury the other unharmed. REST of BODY http://images.gnipherald.com/jousting-thumbnail.jpg base64 encoded gzip compressed binary <--- 200 OK | A note on authentication: Gnip does not support a Filter owner specifying credentials to use on requests that post activities to a Filter's postURL. As an interim solution, a Filter owner can provide an opaque token on the postURL as part of the URL string. If this token is only known to Gnip and the postURL's server, it can be validated on your server when Gnip sends activities to a postURL to ensure that POST requests originate from Gnip. Examples for Publishers Publish Activities to an Activity Stream If you are a Publisher interested in publishing Activities to an Activity Stream, POST application/xml to a Publisher created by you in the following example. For details go here <#Activity_Stream_Publishing>. Required fields are: ** ** If a payload is added you must also include: ** The supported Gnip rule types are: *actor* *tag* *to* *regarding* *source* If you support one or more of the above rule types, the field for that type is required. ===> | |POST /my/publishers/PUBLISHER-NAME/activity.xml | |Accept: application/xml | |Content-Type: application/xml 2009-02-02T17:16:01.000Z post 0.516958128858 http://gnipherald.com/stories/0.516958128858/jousting-gone-bad.xml Vignette-Web-Publisher 38.2638886 -106.126131 Chloride Mine jvaleski http://gnipherald.com/stories/0.516958128858/jousting-gone-bad.html armor staff injury barinek http://apnewswire.com/jousting/accident.html Jousting Event Went Awry Two drunken guys, two jousting sticks, blindfolds and running full bore down a hallway at each other, lead to a night in hospital for two university students. One with chest injury the other unharmed. REST of BODY http://images.gnipherald.com/jousting-thumbnail.jpg base64 encoded gzip compressed binary <--- 200 OK | |Content-Type: application/xml | Success| ------------------------------------------------------------------------ Platform Capabilities and Terminology *Response Codes * * Typical HTTP response codes are used throughout the API. A list of HTTP response codes is here. * Requests that do not need to return data or have failed return an XML document describing the result of the request. Activity Streams Activity streams are collections of activities which may be retrieved and, in some situations, to which activities may be published. Publishers POST new activities to activity streams; they are the start of data flow through the system. Subscribers can retrieve activity data via activity buckets (see the Activity Buckets <#Activity_Buckets> section below). *https://demo-v21.gnip.com/my[gnip]/publishers/PUBLISHER-NAME/activity[notification].xml* | (Replace PUBLISHER-NAME with the name of an actual publisher. The list of current Publishers can be found here )| GET: Returns an XML representation (Activity Stream XML <#Activity_Stream_XML>) of the activity Publisher activity stream. Response Content-Type: application/xml Activity Stream XML An activity stream represented in XML looks like the following. Full Gnip XML schema can be found here . 2008-07-28T11:32:50Z Activity Buckets Activity streams are segmented into buckets based on time. Each bucket contains all the activities for the stream that are reported during the bucket’s duration. Each bucket has an ID that is the time stamp, in UTC, of the first minute bucket. The bucket ID format is |%Y%m%d%H%M%S| (e.g. the strftime conversion spec). For example, bucket with ID |200806090913| would contain all activity reported during between 9:13 am and 9:14 UTC am, inclusive, on June 9, 2008. Activity buckets are only valid for the last 60 minutes. The "current.xml" bucket holds the "current" activities up to one minute. Please note that the current bucket is not static, so retrieving data from this bucket may not be reliable for your application. The same goes for the 0-1 minute old bucket. Until the full minute is up, the bucket will continue to accrue data. *https://demo-v21.gnip.com/my[gnip]/publishers/PUBLISHER-NAME/notification/current.xml **https://demo-v21.gnip.com/my[gnip]/publishers/PUBLISHER-NAME/notification/BUCKET-ID.xml * *https://demo-v21.gnip.com/my[gnip]*/publishers/**PUBLISHER-NAME/**filters/FILTER-NAME/activity**[notification]**/current.xml** *https://demo-v21.gnip.com/my[gnip]*/publishers/**PUBLISHER-NAME/**filters/FILTER-NAME/activity**[notification]**/BUCKET-ID.xml** GET: Returns a representation (Activities XML <#Activities_XML>) of the activity bucket specified. Response Content-Type: application/xml Activities XML Activity definitions are represented as XML documents similar to this. 2009-02-02T17:16:01.000Z post 0.516958128858 http://gnipherald.com/stories/0.516958128858/jousting-gone-bad.xml Vignette-Web-Publisher 38.2638886 -106.126131 Chloride Mine jvaleski http://gnipherald.com/stories/0.516958128858/jousting-gone-bad.html armor staff injury barinek http://apnewswire.com/jousting/accident.html Jousting Event Went Awry Two drunken guys, two jousting sticks, blindfolds and running full bore down a hallway at each other, lead to a night in hospital for two university students. One with chest injury the other unharmed. REST of BODY http://images.gnipherald.com/jousting-thumbnail.jpg base64 encoded gzip compressed binary Activity XML document conform to the following schema. Full Gnip XML schema can be found here . || ... ... *Filters* A Filter consists of rules that are used to match activities flowing through a Publisher's activity stream. Filters may be created, edited, and deleted at will by their owner. Filter rules are OR'd together; there is no AND support. Since your filter is created on a per publisher basis, the URI will reflect the namespace of that publisher ("my" or "gnip"). If a Filter specifies a postURL, new activities that meet the collection criteria will be posted to the specified URL. POSTed activities include *full data* by default. *https://demo-v21.gnip.com/my[gnip]/publishers/PUBLISHER-NAME/filters.xml* GET: Returns the Filters XML document which lists all the filters, including their rules, you own for the specified Publisher. Response Content-Type: application/xml POST: Accepts a Filter XML document and creates a new filter based on that information. If your Filter document is large it should be gzip'd, and sent with the "Content-Encoding: gzip" header. If you wish to update a filter, use PUT, described below. POSTing a Filter twice with the same name will result in an error response from the server. Request Content-Type: application/xml Response Content-Type: application/xml *https://demo-v21.gnip.com/my[gnip]/publishers/PUBLISHER-NAME/filters/FILTER-NAME.xml* GET: Returns a Filter XML representation of the specified Filter. Response Content-Type: application/xml PUT: Accepts a Filter XML document and updates the specified Filter to match the data provided. Gnip will replace the existing Filter with this document. If you're trying to create a Filter for the first time, use POST, described above. For incremental updates of a Filter, see the next section "Editing Filter Rules." Request Content-Type: application/xml Response Content-Type: application/xml DELETE: Removes the specified Filter. *Filter** XML* Filter definitions are represented as XML documents similar to this. | optional joe cars | Filter XML document conform to the following schema. Full Gnip XML schema can be found here . *Editing Filter Rules* A Filter's rule set can be incrementally updated and queried via the Filter's /rules endpoint. The rules endpoint can be used to add a single rule or to batch add a set of rules. The rules endpoint is namespaced based on the Publisher scope (either "my" or "gnip"). Each publisher supports a different set of one or more rules. To review the list of supported rule types, you can view the schema document . Currently, the types are: *actor* *tag* *to* *regarding* *source* To find out if a publisher supports the rule types, you can look at the list of Publishers, the action types they support, and example XML output . * https://demo-v21.gnip.com/my[gnip]/publishers/PUBLISHER-NAME/filters/FILTER-NAME/rules * GET: Accepts a query string consisting of a single rule to search for in the Filter named FILTER-NAME. For example: .../my[gnip]/publishers/PUBLISHER-NAME/filters/FILTER-NAME/rules?type=actor&value=joe Request Content-Type: * Response Content-Type: application/xml Response Codes: 200: if the rule is found in the Filter. The response body will contain the XML of found . 404: if the rule could not be found. POST: Accepts two XML document types: Send a rule XML document (e.g. value ) to add a single rule to FILTER-NAME. Send a rules XML document (e.g. ...) that wraps one or more documents to batch add to FILTER-NAME. For example: .../my[gnip]/publishers/PUBLISHER-NAME/filters/FILTER-NAME/rules.xml Request Content-Type: application/xml Response Content-Type: application/xml Response Codes: 200: if an individual rule is successfully added to the Filter. if sending a document, a 200 will be returned if the document is successfully received, but the server processes a batch update asynchronously, so for a 200 does not imply that they have been added to the Filter. Use either the rules/ endpoint to search for a newly added rule or a GET on the whole Filter to ensure all rules in the batch were added. 400: if adding a with a rule type that isn't supported by the publisher DELETE: Accepts a query string consisting of a *single* rule to be removed from FILTER-NAME. For example: .../my[gnip]/publishers/PUBLISHER-NAME/filters/FILTER-NAME/rules?type=actor&value=joe Request Content-Type: * Response Content-Type: * *Large Filters and the rules endpoint *When using filters on the Gnip Platform, the rule sets can grow "large" and have tens and hundreds of thousands (or more) rules used to match specific types of activities from a given Publisher. In the case of large rule sets, the rule endpoint *must *be used to add rules to a large Filter due to the fact that making incremental changes by GETting, changing, and POSTing the entire XML document causes a needless exchange of many megabytes of data. Instead, large Filters can be incrementally augmented by sending batches of up to 5000 documents wrapped inside a document to the rules/ endpoint. For example, to add 100,000 rules to a Filter that has an existing 100,000 rules, send 20 documents containing 5000 rules each rather than sending 100,000 individual documents to the rules/ endpoint (which could take days) or than sending a PUT of the Filter containing 200,000 rules (which unnecessarily transmits large amounts of repetitive rules). POST: Accepts two XML document types: Send a rules XML document (e.g. ...) that wraps one or more documents to batch add to FILTER-NAME. For example: .../my[gnip]/publishers/PUBLISHER-NAME/filters/FILTER-NAME/rules.xml Request Content-Type: application/xml Response Content-Type: application/xml Response Codes: 200: If the document is successfully received, but the server processes a batch update asynchronously. A 200 does not imply that the rules have been added to the Filter. Use either the rules/ endpoint to search for a newly added rule or a GET on the whole Filter to ensure all rules in the batch were added. 400: if adding a with a rule type that isn't supported by the publisher *Publishers * Publishers are scoped to either be "system-wide" and publicly available (e.g. in the "gnip" namespace), or privately scoped in the "my" namespace. A current list of public Publishers in the Gnip system can be found here . They are owned by a single account and only that account can manipulate the publisher definition and publish activities to its activity stream. A Publisher can move their private "my" Publisher feed to a GNIP endorsed by contacting GNIP. *https://demo-v21.gnip.com/my[gnip]/publishers.xml* * * Different actions can be done by doing a get, post or a delete to the URL above*.* *Retrieve a list of publishers: * GET: Returns a Publisher XML document listing of current Publisher's in the system. Use "gnip" in the URL to return the list of endorsed publicly available publishers and "my" to return your list of publishers. Response Content-Type: application/xml *To create a new publisher:* POST: Accepts a Publisher XML <#Publisher_XML> document and creates a new publisher using that information. Post can only be done to the ".../my" scope. Only GNIP can create GNIP publishers. Request Content-type: application/xml Response Content-Type: application/xml *To delete a publisher you own:* DELETE: Accepts a query string consisting of a single pubisher to be removed using my for scope. Only GNIP can delete gnip publishers. For example: .../my/publishers/PUBLISHER-NAME Request Content-Type: * Response Content-Type: * Publisher XML Publisher definitions are represented as XML documents similar to this. As a Publisher you can define which rules you support. Rule types today are: actor, tag, to, regarding and source. Below is an example of XML that has actor as supported. actor Publisher XML document conform to the following schema. Full Gnip XML schema can be found here . ... ... *Push Recipients * Filters can be subscribed to in such a way that any time activities are published that match the Filter criteria, those activities are pushed, via a HTTP POST, to a configurable URL. The URL to which activities will be pushed is specified by the postURL of the Filter XML. Any activities added to a Filter which has a , will automatically be POSTed to that URL. The body of these POSTs will be an Activities XML document (described above in the Activity Buckets section <#Activity_Buckets>). Responses to these requests are ignored. PostURLs must be valid. *http://mysite.example/inbound-activity-handler.cgi * POST: Pushes new activities, as an Activities XML <#Activities_XML> document, to the subcriber to this collection. Request Content-Type: |application/xml| Activities XML A set of activities are represented in XML documents that look like this. Full Gnip XML schema can be found here . 2009-02-02T17:16:01.000Z post 0.516958128858 http://gnipherald.com/stories/0.516958128858/jousting-gone-bad.xml Vignette-Web-Publisher 38.2638886 -106.126131 Chloride Mine jvaleski http://gnipherald.com/stories/0.516958128858/jousting-gone-bad.html armor staff injury barinek http://apnewswire.com/jousting/accident.html Jousting Event Went Awry Two drunken guys, two jousting sticks, blindfolds and running full bore down a hallway at each other, lead to a night in hospital for two university students. One with chest injury the other unharmed. REST of BODY http://images.gnipherald.com/jousting-thumbnail.jpg base64 encoded gzip compressed binary Errors In the event of Gnip being unable to fulfill a request it will return a response with the most appropriate response code and a human readable message in the body. If the request could not be fulfilled because there was something wrong with the request a 4xx series response code will be used. If the request was not fulfilled for any other reason a 5xx series response code will be used. *Error XML* An error represented in XML looks like this: "foo_bar" is not a valid publisher name. Only letter, number, '.', '+' and '-' characters are allowed in publisher names. Remember, depending on your HTTP client, an message may only be available as part of an error input stream in the event that the server returns an HTTP response with a non-200 response code. For example, in the case of Java's java.net.HttpURLConnection, the message would be available via the getErrorStream() method. *Revision History* * rev 12 - Update to delete URL endpoint * rev 11 - Changed Publishers and Subscribers to Data Producers and Data Consumers. Fixed URLs, added publishing to an activity, did color changes. * rev 10 - changed XML examples from gnipherald publisher to gnip-sample * rev 9 - updated xml examples to include final schema, added delete publisher example * rev 8 - minor editing tweaks * rev 7 - some minor editing tweaks * rev 6 - new schema, version 2.1 * rev 5 - added documentation for batch and search support in the rules/ endpoint. Added documentation to the Activities section of the samples. Rearranged some links and made some XML formatting changes. * rev 4 - updated for publisher capabilities, added paragraph on authentication for activity push, remove references to JIDs, document cleanup * rev 3 - updating publisher activity endpoint to reflect the correct one. * rev 2 - added verbiage to further clarify filter management. * rev 1 - moved bucket-ID API from five minute buckets to single minute buckets * rev 0 - initial cut of the 2.0 document Edit this page (if you have permission) | Google Docs -- Web word processing, presentations and spreadsheets.