If I use this URL to get the Category page
https://en.wikipedia.org/w/api.php?&callback=jQuery111206430303168017417_1453394474227&action=query&prop=revisions&rvprop=content&format=json&titles=Category%3AHacker+(subculture)&_=1453394474245
but I only have a header and other categories, how to get the same page as on Wikipedia with a list of articles?
The Wikimedia API does not return the HTML page as it appears when you browse Wikipedia. If you want that page, you need to call it by its common URL, e.g. https://en.wikipedia.org/wiki/Category:Hacker_%28subculture%29
If you want to use the API to get at the page titles or page ids listed in a certain category, you need to query for category members.
For your query, you would do something like: https://en.wikipedia.org/w/api.php?action=query&list=categorymembers&cmtitle=Category%3AHacker+%28subculture%29
Set cmlimit to get more than the default ten pages. Maximum is 500.
You can then parse the JSON to get at the listed page titles or page ids, e.g. to create links to those pages.
Look at the documentation for an explanation of these and other parameters you may use in your query.
The query uses format=jsonfm (for a readable rendering of the data) as a default. Use format=json for your data query.
Related
Ok, so this has been asked once before with no answers so i'll give it another bash..
On the eBay website one of the first things you do when listing an item is pass in a string which is the listing title. Given this title string, eBay will go and examine all the categories and pick out a short selection of categories where it thinks you listing will be best suited.
I need to use the bulk File Exchange API and need to find the best category programatically. How can I find the most appropriate categories using one of eBays APIs i.e. is there an API for that?
The only solution I have come up with is to get all the categories using those APIs, then traverse the every category performing some kind of ranking on my inputted listing title (cosine similarity or something).
Any ideas, thanks.
Sounds like you may be able to make use of GetSuggestedCategories.
From the documentation:
Specify keywords describing an item you are looking for using the
Query input field. GetSuggestedCategories returns a list of up to 10
categories that have the highest percentage of listings whose titles
or descriptions contains the specified keywords.
Having a doubt on REST API URI design.
Let's consider each Post has one or more tags. So, a tag could be retrieved by
GET /posts/1/tags/1
Tags are stored uniquely in DB with an ID. So I could access full detail of a tag using
GET /tags/1
If Post information needed, then I could use query parameter
GET /tags/1?post=1
My question is why the first format widely suggested over second/third format.
Suggest me use case/scenario to prefer first format or complications with second/third format.
why the first format widely suggested over second/third format.
This is not the case. The three are used for different things.
You must first ask if a tag can exist without a post. I'd say yes. Because of this, the second form
GET /tags/1
is a good URI to get the representation of a tag.
Next, ask yourself if a post can have multiple tags. I'd again say yes. Because of this the first form is a good way to get a specific tag of a post. More general, the form
GET /posts/1/tags
returns all tags that are used for post 1. This is a collection resource. One of those tags is tag 1 which can be navigated to by
GET /posts/1/tags/1
Note that the first and the second form both identify tag 1. Both forms can be used at the same time.
The third form makes no sense at all. Query parameters after the ? like post=1 are generally used to filter a collection resource. One could say: "Give me all tags that are used on posts 1, 23, and 42. This could be formulated as
GET /tags?post=1,23,42
Here we filter the collection resource of all tags by a condition.
Your third form uses a query parameter post=1 on a single resource. But it makes no sense to filter a single tag.
A fourth form could be useful: Give me all posts that use a tag:
GET /tags/1/posts
This would return the collection resource of all posts that use tag 1.
And even a fith form with the same meaning as fourth would be possible:
GET /posts?tag=1
Summary:
When thinking about REST URIs, think about resources. What are your resource? What are the relations between them? Can one type of resource exist only "inside" another type of resource (a hotel room can only exist inside a hotel) or can it exist on its own (a tag can exist even if not post is tagged with it). What could be a subresource of another resource? What collection resources exist? How can they be filtered?
Is there any way to get random article of specific wikimedia portal using wikimedia API?
For example, I need random page of Portal:Science.
Does anyone know how to do this?
What you're asking for doesn't make much sense, because a portal doesn't have a list of pages associated with it.
The closest thing you can do is to get a random page from e.g. Category:Science or one of its subcategories. There is no way to do that directly using the API, you would need to traverse all the subcategories and choose a random page from them by yourself.
There is a tool that already does this (with a limit on the depth of the category tree): erwin85's random article and there is also a template for it on the English Wikipedia.
I'm trying to query Picasa Web Albums to pull album/photo data (obviously!) however initially I only need to pull the first 4 photos. Is there any way to limit a particular field or specify the items per page?
I've already accomplished something similar with Facebook's Graph API however I'm unable to find anything similar for Picasa. The only items I can find related to limiting the response is specifying which fields, but nothing related to the number of rows.
Use max-results argument. See doc here.
https://developers.google.com/picasa-web/docs/2.0/reference#Parameters
I start implement a REST API. I have a request doing on a resource with multiple entries. To implement the pagination, I do like Github choose implement it.
I define a HTTP Header Link where I add the next/previous/first/last link.
Link: <https://api.github.com/repos?page=3&per_page=100>; rel="next",
<https://api.github.com/repos?page=50&per_page=100>; rel="last"
In my body there are only my entries and nothing else. But Now I want know how entries there are in total. I can't do a multiplication between number of page and per_page entries, because the result is not exact.
So how can I do to return this number to entries ? I think add a new HTTP Header in my answer X-total-entries. But I don't know if there are better technique or not.
When I try to decide whether to put some data into the headers or into the body, I ask myself if it is a feature of the application or of the protocol? In your case, is the pagination a feature of the application? Is the user aware what page he is looking at? Is the total number of items displayed to the user? If the answer is yes, then I would put the information into the body. Then the body becomes not just a list of items, but a representation of a page, with all the information and controls needed to display it. Only if the pagination is a internal protocol detail would I consider putting the links and the item count into the header. I know this may sound a rather abstract way of thinking, but if the pagination details need to bubble up all the way to the top of the application, there is little real benefit in separating this information from the body and putting it into the headers.