The DHS Program User Forum
Discussions regarding The DHS Program data and results
Home » Dissemination and Capacity Strengthening » Application Programming Interface (API)  » is "perpage" query param supported for data API? (API)
is "perpage" query param supported for data API? [message #17750] Tue, 21 May 2019 17:32 Go to next message
larshelge@baosystems.com is currently offline  larshelge@baosystems.com
Messages: 3
Registered: May 2019
Member
Per the docs, "perpage" query param controls page size:

> perpage: Indicates maximum number of rows returned. Maximum is 1000 for non-authenticated users, and 5000 for authenticated users. Default is 100

Is this supported for the "data" API endpoint? It does not appear so from this URL, as I still get 100 rows back:

http://api.dhsprogram.com/rest/dhs/v7/data?countryIds=EG& ;perpage=1000

For this query, "perpage" makes the backend crash:

http://api.dhsprogram.com/rest/dhs/data/FE_FRTR_W_TFR&pe rpage=1000

Is this a bug? If not, could support for the "perpage" param be added to the data endpoint?

Thanks!
Re: is "perpage" query param supported for data API? [message #17751 is a reply to message #17750] Tue, 21 May 2019 17:56 Go to previous messageGo to next message
Trevor-DHS is currently offline  Trevor-DHS
Messages: 805
Registered: January 2013
Senior Member
Hi,

For the first link, there should be no semicolon (;) in the call (the link is correct, but the display here is adding a semicolon that should not be there):

http://api.dhsprogram.com/rest/dhs/v7/data?countryIds=EG& ;perpage=1000

However, you are right that there is a bug and the API is only returning 100 records instead of the number specified in the call.

For the second link, the call should use a question mark (?) before the perpage parameter. The reason is that the API supports two types of parameters:
1) RESTful parameters and Query-based parameters. RESTful parameters follow a slash (/) following the basic endpoint (e.g. FE_FRTR_W_TFR is a RESTful parameter). RESTful parameters are separated by commas (,).
2) Query based parameters can then follow the RESTful parameters, and follow a question mark (?). Query based paramters are of the form param=value, so perpage=1000 is a restful parameter, as is countryIds=EG. Query based parameters are separated by ampersands (&).

In the second example you have a RESTful parameter (FE_FRTR_W_TFR) and a query based parameter (perpage=1000).

You could also write the following:
http://api.dhsprogram.com/rest/dhs/data/FE_FRTR_W_TFR,EG?per page=1000&f=html
which has two RESTful parameters (FE_FRTR_W_TFR and the country code EG, separated by a comma) and, following the question mark, two query based parameters (perpage=1000 and f=html separated by an ampersand (&)).

I hope this helps. We will get the perpage parameter corrected quickly.

[Updated on: Tue, 21 May 2019 18:02]

Report message to a moderator

Re: is "perpage" query param supported for data API? [message #17752 is a reply to message #17751] Tue, 21 May 2019 18:06 Go to previous messageGo to next message
larshelge@baosystems.com is currently offline  larshelge@baosystems.com
Messages: 3
Registered: May 2019
Member
Hi Trevor,

great, thanks for the quick reply.

The semicolon I think was an encoding issue when copy-pasting from browser; I did not have it locally.

In the second example you are right, clearly should have used ?. (Minor issue, you could argue 404 is the correct API response instead of a server side error.)

Many thanks for the explanation on REST vs queries. Appreciate it.

Lars

Re: is "perpage" query param supported for data API? [message #17758 is a reply to message #17752] Wed, 22 May 2019 17:35 Go to previous message
larshelge@baosystems.com is currently offline  larshelge@baosystems.com
Messages: 3
Registered: May 2019
Member
Hi,

can confirm that

http://api.dhsprogram.com/rest/dhs/v7/data?countryIds=EG& ;perpage=1000

works properly now. Thanks for the quick fix!

Previous Topic: Child health data in API
Next Topic: How to use API to import data to R/Stata
Goto Forum:
  


Current Time: Sat Dec 7 13:02:11 Coordinated Universal Time 2024