Querying "Pepper Public API" with requests - rest

I'm trying to query the HotUKDeals API. The page says
This API follow some of the REST idioms.
It is available under the https://{hostname}/rest_api/v2 root URI.
At the top of the page, it says
https://www.pepper.com/rest_api/v2
So I have tried writing
import requests
r = requests.get('https://www.pepper.com/rest_api/v2')
r.status_code
as per the requests documentation. However, this returns 404.
Does this mean that the HotUKDeals API isn't working, or am I making a mistake in querying it?
Disclaimer: I've been using Python for couple of years but am a requests noob.

the problem is that this Api does only gives you 200s to actual querys. (You need to add something behind v2 as mentioned in the docs)

Related

REST expected behavior of entity filter within collection

Could somebody help to find out the expected behavior in filtering data within REST.
I have an ordinary REST-service with API
GET /api/articles <-- extract all articles
GET /api/articles?category=1 <-- extract all articles belonging the
particular category
I have doubts regarding the second stuff. What must a request return if user set an invalid category. There're 3 options:
return all articles
return an empty collection
return error
I suppose that it might be up to me, but anyway I wonder whether somebody have implemented this and how he/she resolved it.
You have answered your question yourself, but to provide you an example how this is already implemented (in numerous cases) but just pointing to one such example using JIRA.
You can use JIRA's REST APIs to GET the ticket details and which is what I'm showing you here:
Using CURL, I've tried to get the ticket details providing an invalid JIRA ticket id and the above is the response that I received.
It is up to us to decide upon what needs to be the outcome of the REST APIs that we develop, just pointing out one of the scenarios from JIRA REST APIs where they chose to error out (instead of showing no response or etc).
Hope this answers your question well!

Get Post Insights for multiple posts in one call using Graph Api 2.7

I am trying to get post insights for a page feed using Facebook Graph API version 2.7 ..
If I only write:
'[Page ID]/feed?fields=insights'
It asks for metric, which indicates it should work... But when specifying a metric:
'[Page ID]/feed?fields=insights/post_impressions/lifetime'
I get syntax error.
I've tried with . notation as:
'[Page ID]/feed.insights/post_impressions/lifetime'
But stil no luck!
I know I can do it post by post (separate calls to API), but that is what I'm trying to avoid.
Anyone know what the correct syntax is for nested insights?
This bug report was able to shed some light: https://developers.facebook.com/bugs/1755454881375647/
You can use the metric keyword to specify the metrics you want, like so:
/page-id/posts?fields=insights.metric(post_impressions,post_consumptions_unique)
Name the metrics you are interested in there, and separate them with a comma.
Specifying the period (where applicable) seems to work by the same kind of syntax,
/…?fields=insights.metric(…).period(lifetime)
(Although it might not work to request different periods for different metrics in one go.)

Proper way to structure my REST api in this case

I am trying to build a little web application with the MEAN stack (MongoDB, ExpressJS, AngularJS and NodeJS).
My question is very simple. If you take the example of a blog, it will contains blog posts, that you could list at this url:
GET /api/posts
You could also get the comments for that posts:
GET /api/posts/:postId/comments
and get a single comment:
GET /api/posts/:postId/comments/:commentId
The relation between post and comment is really obvious here, but does it still makes it mandatory to have it this way? or could I just perform my CRUD operations through /api/comments? In the end, a comment object in mongodb will always have a postId attribute anyway which will reference the post that it is related to... Moreover, the API will not be exposed and is strictly meant to be used by the application.
does it still makes it mandatory to have it this way?
No. This is not mandatory at all.
or could I just perform my CRUD operations through /api/comments?
Yes. This will result in cleaner resources URIs (endpoints).
You can also get post-specific comments with:
GET /api/comments?postId={postId}
Further, you could also drop the /api prefix if you are serving only an API at the given host.

Get all status's from JIRA webservice

Is there a way to get all status types from the JIRA webservice, either through the api or through a JQL request? (The issue status is the field that is mapped to the swimlanes when the board is set up)
Whith JIRA REST API you can :
rest/api/2/status
or for each project :
rest/api/2/project/{projectIdOrKey}/statuses
see the online rest api browser : it's a wonderful tool :
https://jira.atlassian.com/plugins/servlet/restbrowser#/resource/api-2-status
For future reference, to see what's in a project's swimlanes for a JIRA agile board you make a request like this: https://jira.atlassian.com/rest/greenhopper/1.0/xboard/work/allData.json?rapidViewId=560 and it will return the relevant information.
Each board has a rapidViewId so you'll have to query for that yourself using a request like this: /rest/greenhopper/1.0/rapidview.
All this stuff can be found here: https://jira.atlassian.com/plugins/servlet/restbrowser#/resource/greenhopper-1-0-rapidview
This is for future reference so that people don't have to go through the same trouble I did when trying to figure this out. Hope it helps!

Facebook Places API 500 result limit

Facebook OpenGrap API limit results of [id]/checkins to 500. Is there are way to retrieve more than 500. Example if I want to retirve all the place someone has checkin for year 2011. What are possible available methods. Is there a premium service provided by Facebook.
Regards,
Waruna.
As the open grpah documentation describes, there should be a "paging" object at the end of the api response if there is more content than you could load at one time. You can test this by clicking the example links inthe documentation. So, the solution is: Loop your requests until there is no "next" property in the "paging" object of the response.
Also there are possibilites to batch your requests, maybe this is also useful for you.