I am trying to figure out how to use the HTTP request URL's provided by the stubhub Listing Catalog Service request page here: http://stubhubapi.stubhub.com/index.php/Anatomy_of_a_Listing_Catalog_Service_HTTP_Request
I looked at the example at the sample HTTP request, why does this: http://www.stubhub.com/listingCatalog/select/?q=%2B+stubhubDocumentType%3Agenre%0D%0A%2B+leaf%3Atrue%0D%0A&version=2.2&start=0&rows=10&indent=on return what it returns?
How to I modify this link to return only, say, Yankees game at Fenwick park?
According to the Stubhub API Reference, the sample url:
http://www.stubhub.com/listingCatalog/select/?q=%2B+stubhubDocumentType%3Agenre%0D%0A%2B+leaf%3Atrue%0D%0A&version=2.2&start=0&rows=10&indent=on
is the following SOLR search query, converted to a URL query string:
+stubhubDocumentType:genre
+leaf:true
This actually looks more like
+stubhubDocumentType:genre\n+leaf:true
and finally encoded to URL query
%2B+stubhubDocumentType%3Agenre%0D%0A%2B+leaf%3Atrue%0D%0A
http://www.stubhub.com/listingCatalog/select/ is the endpoint
the parameters on the end specify options
For Yankees at Fenwick park, you would probably want to search for Stubhub Events that are located in Fenwick park and have New York Yankees in the description.
You should take a look at this PHP example, which contains how to search the search for a specific search query.
For easy access to the Stubhub Api, check out a Ruby Gem that is a good wrapper for the API.
Related
Twitter has private endpoints like this one:
http://urls.api.twitter.com/1/urls/count.json
Tweet counts can be fetched from here, but this is not recommended by Twitter. Besides, they keep saying they gonna shut down these endpoints in the near future.
The Site Streams API is now in closed beta, they don't accept applications.
https://dev.twitter.com/streaming/sitestreams
So that leaves is with only one option, the REST API, but I don't see any endpoint there which could return the number of tweets for a given URL.
What's the best way to get this data? Is there an "official" endpoint for this?
Or the only way is to use something like the Public stream API or the REST API search endpoints and filter the results?
The private endpoint will be shut down by 20 Nov and there'll be nothing to replace it. This blog post from Twitter explains the background: apparently it's to do with their move to their new "real-time, multi-tenant distributed database" system codenamed Manhattan.
The REST API will be of limited use for this purpose. You'd have to do a search for your URL, collect each page of results and add up the total number of tweets yourself. For example this request
https://api.twitter.com/1.1/search/tweets.json?q=metro.co.uk&count=100
will get tweets associated with http://metro.co.uk. (It won't work if you just paste this into your browser - you have to authenticate first. You can try this on the Twitter API console tool.) But the Search API returns a max of 100 tweets per page of results, and it only returns tweets from the last 7 days.
It seems the only solution (explained here) is an elaborate one using a Twitter Streaming API. Basically you'd have to create your own app to count relevant tweets. It would open a connection to stream.twitter.com passing your URL as a track parameter. Twitter will return a tweet every time anyone tweets the address, and your app will have to count them. The example given in that post is:
curl -u user:password "https://stream.twitter.com/1/statuses/filter.json" -d "track=https%3A%2F%2Fdev.twitter.com%2Fdiscussions%2F5653"
I'm not sure how you would deal with shortened URLs in this scenario.
This change has meant that third-party services like SharedCount that report a count of Twitter shares are having to stop offering that data. Sorry to give you bad news - I'm really disappointed with this situation myself. It seems crazy that we can't just get a total of tweets for a given URL.
You can find a little bit more about this in this thread.
We can get text extract of different pages in a single wiki api call by using pipe character ( | ).
For eg : http://en.wikipedia.org/w/api.php?format=json&action=query&prop=extracts&exlimit=max&explaintext&exintro&titles=Yahoo|Google&redirects=
By using this api call, we can get datas about Google and Yahoo in text format. Here we get datas of both Google and Yahoo in a single api call.
I want to get image urls of both Google and Yahoo in a single wiki api call.
Is there any method to get all image urls of different pages in a single wiki api call?
Yes, just switch prop=extracts to prop=images. Works exactly the same way:
http://en.wikipedia.org/w/api.php?action=query&titles=Yahoo|Google&prop=images
The full documentation is here: http://www.mediawiki.org/wiki/API:Properties
To get the url of an image, use prop=imageinfo&iiprop=url for the corresponding file page.
Finally, you can combine it all in one single request, by using the prop=images result as a generator for the prop=imageinfo call:
http://en.wikipedia.org/w/api.php?action=query&prop=imageinfo&iiprop=url&generator=images&titles=Google|Yahoo!
There are some warning because you are missing the format=json. So the correct is
https://en.wikipedia.org/w/api.php?action=query&prop=imageinfo&format=json&iiprop=url&generator=images&titles=Google|Yahoo
I have a vb.NET App that uses System.Net.WebClient to query an API. I'm able to get the information I'm requesting just fine.
The people that supply the API are requesting that I
"set a custom User header when requesting data to determine the source application."
Am I supposed to pre-send something first, or append something to the url for the WebClient to processes? The API only accepts get requests and it doesn't have a parameter for an identification.
I'm stuck in terminology here. A search for that phrase, here, came up with server-side topics so I don't know what to look for. Can someone translate?
How can i use Google search api to get like on the google engine, title of website,a short description and URL. Is it possible?
I tried the api but it gives me only some information that doesn`t have a url or title to a website.
Using the Google shopping api, you can retrieve the title, short description and url. I've achieved this in a c# application where it returns a json file from the url below and parse over it.
You need a apiId to start with.
Using this url you can add search parameters after the q, in this example just searching for digital camera.
https://www.googleapis.com/shopping/search/v1/public/products?key=key&country=US&q=digital+camera
See http://code.google.com/apis/shopping/search/v1/getting_started.html
for more details
I'm not sure that I have enough information, but I find the Google Custom Search API reference page has the reference JSON/ATOM examples:
https://code.google.com/apis/customsearch/v1/reference.html
This query will get you started:
https://www.googleapis.com/customsearch/v1?key={YOURAPIKEY}&cx={cx?}&cref={cref?}&q=st%20olaf
Does this get you started?
Take care!
speeves
Is it true that to implement a RESTful API, one has to implement a URL structure that looks like this
http://example.com/post/
http://example.com/post/123
where the /123 would be used for edit, delete
Another way to ask the question is: can a URL that looks like this be called RESTful?
http://example.com/script.php?method=get_title&blogid=123
You don't have to design your URI structure like that. It could also be /some_obscure_string/base64_encoded_title/unique_id. This could also be RESTful, depending on several other factors.
But there are several best practices on how to design URIs in a RESTful web application and being as simple and as human readable as possible is one of them.
Your example http://example.com/script.php?method=get_title&blogid=123 could also be RESTful, but the query parameters indicate that some kind of RPC- or RMI-over-HTTP is used instead.
To sum it up: Don't put too much thought into your URI design. This will come automatically with a good and proper RESTful design of your application.
The Idea behind REST is that every resource has it’s own URL and you use the different HTTP methods to interact with those resources. It makes sense to define the URL structure so that the hierarchy between different resources is reflected in the URL, but you don’t have to.
If you have URLs like this
/all-posts/
/first-post
/some-stuff/second-post
/third-post
you still could provide an RESTful API to this. The Idea is that a GET to /all-posts/ returns a list of the URLs of every post object and the client uses those URLs to interact with the resources. Basically the URLs should be treated as opaque data by the client.
As long as the URL that is embedded in the client doesn’t change you also could change the structure without having to change the client.
Your example URL probably doesn’t belong to a RESTful API, since it contains a method get_title. In REST a URL represents a thing. What is to be done with the thing (should it be modified, should it contents be retrieved, ...) is not part of the URL, for that REST uses the different HTTP methods.
A key aspect of REST is that the url is the resource. a uri like
http://example.com/script.php?etc-etc-etc
doesn't put the resource identifier in the resource portion of the uri. that's not to say that a RESTful API shouldn't ever use get parameters; in fact, that's just fine:
http://example.com/posts?sort=date_asc&offset=20&limit=10
might be a great way to get the URI's of the 3rd page of oldest posts. However, using get parameters in this way should only be used in requests where the method is also GET. PUT and especially POST methods should really use simple uri's with the resource that will be affected in only the path portion.
RESTful URI design is all about resources access and they should be structured in the RESTful manner, so you should not have any query strings.
e.g. of GET
authors/
authors/1
authors/1/books
authors/1/books/10
authors/1/books/10/summary
etc.
Anything and everything is called RESTfull these days, just look at some of the responses by it's inventor Dr Roy Fielding and you'll get some ideas. It is worth doing some reading on the subject.
P.S you do not need post,get etc in your URIs, HTTP protocol is at present mostly used for consuming REST APIs and you can pass verb as a part of the call. Also there is a concept of content negotiation i.e you can request any available format from REST API (json,xml atc).
The REST concept is really based on the fact that it is URL driven, and not driven by large data-blobs. With REST, you don't have to pass a giant soap request to invoke a method - your method call/object creation/whatever you want to do is invoked simply by the URL, and the verb you used vs that URL.
Example URLs:
GET http://del.icio.us/api/
GET http://del.icio.us/api/peej/tags/
GET http://del.icio.us/api/peej/tags/test
DELETE http://del.icio.us/api/peej/bookmarks/[hash]
The structure of your URLs doesn't matter. What does matter is that each URL identifies exactly 1 resource. Each resource can have multiple URLs that point to it but each URL should only point to 1 resource.
This can be helpful. Ref:
RESTful service URLs