Is it possible to retrieve only one item information from amazon api using ItemSearch operation?
Now I am getting 10 records for a book search.
I'd like to see only single item-information. For example: for a C# book search, I'd like to see only one complete information.
If you want to see the details of only one product, then you must perform ItemLookup.
Given an Item identifier, the ItemLookup operation returns some or all of the item attributes, depending on the response group specified in the request.
ItemLookup supports many response groups. Response groups return product information, called item attributes. Item attributes include product reviews, variations, similar products, pricing, availability, images of products, accessories, and other information.
Related
I was pretty deep into integrating Stream into my existing pagination implementation (which is also used for paginating non-activity data stored in MySQL) when I came across this line in the Stream documentation under "Custom Ranking":
Please note: offset and id_lt cannot be used to read ranked feeds. Use score_lt for pagination instead.
This seems to be the only mention of score_lt in the docs. I can't find it discussed anywhere else, nor can I find an example of what its value should be. Should it be the same UUID I would use for id_lt if I were paginating a non-ranked feed? Or is it meant to be a score value of some kind that would be returned only by a ranked feed?
Normally I'd just try it and see, but ranked feeds are only available to paid plans and I'm still evaluating Stream.
This could have significant implications for how I implement pagination though, since I do want to be able to use ranked feeds in the future if I move forward with Stream.
When retrieving activities from a ranked feed using a specific ranking config, each activity will include a score attribute. You can use the score_lt to paginate through the items in the ranked feed (along with the limit parameter).
(When paginating through items on non-ranked feeds, we usually recommend using the id_lt parameter, which will just return activities by creation date, in chronological order from most-recent to least-recent. However, since older content in a ranked feed might be ranked higher than newer content, we have to paginate and order via the score attribute.)
--
Whenever you create a ranked feed, you'll create at least one ranked feed config. I'm going to name my ranked feed config ranked-feed-config-one (you can have as many as you'd like) which will look something like this:
{
"score": "decay_linear(time) * popularity ^ 0.5",
"defaults": {
"popularity": 1
}
}
Whenever you send a new activity into stream, you'll also provide an optional popularity parameter. (If you don't provide one, popularity will default to 1.)
Then, whenever you retrieve activities from the ranked feed, you can specify what ranking config you'd like to use (ranked-feed-config-one), like this:
someFeed.get({ ranking: 'ranked-feed-config-one' })
Each activity will be returned with (and ordered by) a score attribute. You'll save the last score attribute, and use that when supplying the score_lt parameter for future pagination calls.
--
Hopefully that helps clear things up! Let me know if there's anything else I can help answer for you.
You can use Limit & Offset Pagination.
someFeed.get({limit:20, offset:20})
Is it possible to implement filtering on feeds in stream? I would like to allow users to follow other user posts but have those tagged with various categories. The desire is to select a category of Football and see just the posts made by people I follow which have that tag or potentially a collection of tags if the category was All Sports for example.
Looking in the api and docs it seems that a feed is pivoted on a single attribute so I can do a request for all posts of people I follow but not all posts for people I follow that are about NCAA or NFL.
Currently the getstream-io api does not have any filtering capability for the retrieval of activities. All possible options for retrieval of activities can be found in the REST docs
This question is complementary to Retrieving more than 150 Instagram comments and a repetition of this older post in the group.
Currently it appears to be impossible to retrieve a full list of likes or comments for a specific post. There are no documented pagination parameters, and it is unclear how one could paginate over likes as they have no publicly exposed timestamps or time-related identifiers.
At the very least the developer documentation on http://instagram.com/developer/endpoints/comments/ and http://instagram.com/developer/endpoints/likes/ should be amended to mention that it is not possible to get a full list of either comments or likes.
Are there any workarounds for this, or plans to support pagination for the comments and likes endpoints?
If no such plans exist, how about allowing for control over the ordering of results? This would at least allow for new entries to be retrieved with reasonable confidence.
At the moment, it looks like the /likes endpoint returns results in newest to oldest order, but unfortunately the comments endpoint uses oldest to newest.
So, I'm building an application in Angular which would leverage a REST API at the back, running on Node. I'm having some trouble handling the data complexity while designing this API and could use some help.
Here are the different resources, in question.
Doctors (each doctor may have multiple patients)
Patients (each patient may have multiple doctors)
Appointments (appointments exist for doctors, naturally)
Reminders (reminders may be sent from doctors to patients, not the other way around)
Now, here are some of the operations that the application may carry out, so the requirements from the API are clear.
Each doctor must be able to request for all his patients or a particular one.
Each patient must be able to request for all his doctors or a particular one.
Each doctor must be able to request for all his appointments (to see all patients) for a particular date, or for all days, if necessary.
Each patient must be able to request for all his appointments (to see all doctors) for a particular date, or for all days, if necessary.
Each doctor must be able to request for all appointments from a single patient.
Each patient must be able to request for all his appointments from a single doctor.
Each doctor must be able to request for all his reminders to a particular patient.
Remember, the request could naturally be a POST, GET, DELETE or PUT. Now, here is where I am so far. I'm only mentioning the URL, the operation on each when sent a POST, GET, DELETE or PUT is self-explanatory.
/doctors/
/doctors/:id
/doctors/:id/patients (returns a list of /patient/:id)
/doctors/:id/appointments
/patients/
/patients/:id
/patients/:id/doctors (returns a list of /doctors/:id)
/patients/:id/appointments
Now, I'm okay with the ones above. Here are my questions.
How do I design a URL for task number 7 without having nesting like /doctors/:id/patients/:id/appointments?
Also, I can get all appointments for a doctor or for a patient quite easily with the above. What about particular appointments? /doctors/:id/appointments/:id or /patients/:id/appointments/:id doesn't feel quite right.
Also, what about appointments to see a particular patient or a particular doctor?
And what about appointments for each doctor or patient on a particular date?
I feel like too much nesting is going on. Please help.
Your list of endpoints looks good. I guess there can be different opinions about what you asked.
The following are my opinions about what could be done:
How do I design a URL for task number 7 without having nesting like /doctors/:id/patients/:id/appointments?
I would suppose a collection of reminders would exist and define it as follows:
/doctors/:doctorid/reminders
/doctors/:doctorid/reminders/:patientid
Also, I can get all appointments for a doctor or for a patient quite easily with the above. What about particular appointments?
/doctors/:id/appointments/:id or /patients/:id/appointments/:id
doesn't feel quite right.
There is no need to complicate the endpoints to that level. If you already know the appointment id why would you reach it through the doctors or patients endpoints? It does not not matter, you reach the item directly through its collection.
/appointments/:appointmentid
Also, what about appointments to see a particular patient or a particular doctor?
You can leverage the power of query parameters for this kind of thing. Not everything has be part of the URL template. Features like filtering of specific records could be added to the query parameters instead. For instance
/doctors/:doctorid/appointments?pantientName=
/patients/:patientid/appointments?doctorName=
And what about appointments for each doctor or patient on a particular date?
Same thing here, you could something like:
/patients/:patientid/appointments?from=&to
Or have special endpoints for very well know cases like, my appointments for today, for this week, for this month:
/patients/:patientid/appointments/:year
/patients/:patientid/appointments/:year/:month
/patients/:patientid/appointments/:year/:month/:day
These latter could actually reuse the same logic used to implement the one getting appointments between a range of dates.
The URI structure is not a REST concern, because according to the uniform interface constraint it has to be decoupled from the client.
What matters:
A specific URI (including the path and the query) can identify only a single resource.
The URI is mapped to the resources and not to the operations, so if you use human readable nice URIs, then they will contain only nouns.
How do I design a URL for task number 7 without having nesting like
/doctors/:id/patients/:id/appointments?
You can map reduce the existing appointment collection, like so:
/appointments?doctor=1&patient=1
/appointments/doctor:1/patient:1
And what about appointments for each doctor or patient on a particular
date?
You can use a date filter to do that:
/appointments?date=2014-09-02
/appointments/date:2014-09-02
I've just gotten into the Adwords API for an upcoming project and I need something quite simple actually, but I want to go about it the most efficient way.
I need code to retrieve the Global Monthly Search Volume for multiple keywords (in the millions). After reading about BulkMutateJobService, in the Google documentation they say
If you want to perform a very large number of operations (up to 500,000) on your AdWords campaigns and child objects, use BulkMutateJobService
But later on in the page they give limits of
No more than 25 OperationStream objects are allowed.
No more than 10,000 operations are allowed per BulkMutateRequest.
No more than 100 request parts are allowed.
as well as a few others. See source here http://code.google.com/apis/adwords/docs/bulkjobs.html
Now, my questions:
What do these numbers mean? If I have 1 million words I need information on, do I only need to perform 2 requests with 500K words each?
Also, are there examples of code that does this task?
I only need Global Monthly Search Volume and CPC for each keyword. I've searched online, but to no avail have I found any good example or anything leaning in that direction that utilizes BulkMutateJobService.
Any links, resources, code, advice you can offer? All is appreciated.
The BulkMutateJobService only allows for mutates, or changes, to the account. It does not provide the bulk retrieval of information.
You can fetch monthly search volume for keywords using the TargetingIdeaService. If you use it in STATS mode you can include up to 2500 keywords per request.
Estimates CPC values are obtained from the TrafficEstimatorService. You can request up to 500 keywords per request.
FYI, there is an official AdWords API Forum that you can ask questions on.