I need to trace bid responses to an entity in my application. Is there any way to achieve this?
Eg. for each bid request set some bids[0].custom, and then have it in response.custom.
Right now my approach is to make each bid request in a dedicated adunit, since every bid response contains adunit property. I am wondering if there is any cleaner and more native way.
The way you suggest is actually the recommended way by the Prebid team as well. In their API docs they offer a way to access bid responses by adunit name, pbjs.getBidResponsesForAdUnitCode. However, if you wanted to modify Prebid source code to achieve some sort of unique id targeting between your bid request an responses beside the ad unit name and ad unit code you could access the adaptermanager.js file in src folder and within the makeBidRequests hook, add a property to the bidderRequest object in the clientBidderCodes.forEach loop. You would also then need to handle that property in the bidResponse equivalent.
Related
A person can have many reviews. My endpoint to CREATE a new review is:
post /person/{id}/reviews
How about the endpoint to UPDATE a review? I see two options:
Stick to the parent resource: patch /person/{person_id}/reviews/{id}
Only have reviews in the URI: patch /reviews/{id}
I could be sold on using either of them:
It's consistent with the previously defined endpoint, but {person_id} is not needed.
It's 'efficient' as we're not specifying a parameter ({person_id}) that is not really needed. However, it breaks the API convention.
Which one is preferable and why?
The client shouldn't have to know about ids at all. After a client creates the review, the response should include the URI to the new review like this:
HTTP/1.1 201 Created
Location: /person/4/reviews/5
The client now has the full URL to the review, making it completely irrelevant how it looks like and what information is here.
Don't forget that the URL itself is a system to create globally unique IDs, that embed not just it's own unique identity but also information on how to access the data. If you introduce a separate 'id' and 'person_id' field you are not taking advantage of how the web is supposed to work.
In terms of API design, without knowing too much detail about OP's situation I'd walk along these guideposts:
Only have reviews in the URI: patch /reviews/{id}
It's 'efficient' as we're not specifying a parameter ({person_id})
that is not really needed. However, it breaks the API convention
The "efficiency" allows for a more flexible design. There's no existing API convention broken at this point. Moreover, this approach gives you the flexibility to avoid the need of always needing the parent resource ID whenever you display your items.
Stick to the parent resource: patch /person/{person_id}/reviews/{id}
It's consistent with the previously defined endpoint, but {person_id}
is not needed.
The consistency aspect here can be neglected. It's not beneficial to design endpoints similarly to other endpoints just because the previous ones were designed in a certain way.
The key when deciding one way or the other is the intent you communicate and the following restrictions that are put on the endpoint.
The crucial question here is:
Can the reviews ever exist on their own or will they always have a parent person?
If you don't know for sure, go for the more flexible design: PATCH /reviews/{id}
If you do know for sure that it always will be bound to a particular person and never can have a null value for person_id in the database, then you could embed it right into your endpoint design with: PATCH /person/{person_id}/reviews/{id}
By the way, the same is true for other endpoints, like the creation endpoint POST /person/{person_id}/reviews/{id}. Having an endpoint like this removes the flexibility of creating reviews without a person, which may be desirable or not.
I am working on a script (which is in Python) for doing some management on our Magento environment.
Now I am wondering if I can create categories with assigned ID.
I think this might be impossible due to key constraints. But is there a way?
Just putting category_id in the parameter list in catalog_category.create, it does not work, it just skips the parameter.
The main reason of wanting this is because I need to know the category ID in order to create the subcategories.
I do know the Magento API returns the ID of the created category. But, I have no way of knowing what subcategories are supposed to go to that created category. (Or I can rewrite a load of code, which I am not too fond of...).
So I was thinking this was the easiest way to go with right now.
Any suggestions, comments, answers? Anything is appreciated!
No, you can't. Magento's entity IDs are for Magento so you cannot specify what you'd like them to be.
When you create an entity with the API it will return the new ID, as you've said.
For your use case it might be easiest to add a new attribute to your categories in Magento, call it "my_category_id" or something and allow your API to set that instead.
I am trying to get the data to create the burned down chart from version one.
I came to know there is no standard api's for that.
Here i found that by making multiple call's to fetch todo value for a scope of timebox it is possible.
Is there any better way to do it?
and also let me know any good open source libraries(javascrpt/java) to plot such graph
i tried the way shown here but i am not able to make out what value i am getting.
i tried a get request like
"base URL"/rest-1.v1/Data/Timebox?where=State.Code='ACTV'&asof"11-25-2015"&sel=Name,EndDate,State,Workitems.ToDo.#Sum
but could only get present value but not the past ones.
Thanks in advance
You are using the rest-1.v1/Data endpoint. From this endpoint you will get the current state of assets in your VersionOne instance however, there is an attribute "Prior" which contains the previous state of a VersionOne asset (Timebox). The most robust way to access historical data is though the rest-1.v1/Hist endpoint. You can find details about Hist queries here.
Using your query
"base URL"/rest-1.v1/Hist/Timebox?where=State.Code='ACTV'&asof"2015-11-25T17:30:00.00"&sel=Name,EndDate,State,Workitems.ToDo.#Sum
The asof keyword will return the state of that Timebox at that instance in time. Observe the proper format of the date.
QuickBooks Online (QBO) uses a URL format like qbo.intuit.com/app/timeactivity?txnId=123 to point to, in this example, a TimeActivity.
However, in the API, resources are referenced by entityId (returned as just Id when querying via the TimeActivity API), which is different from txnId.
In my time tracking web app, I have a feature that exports time to QBO as TimeActivities. I'd like to provide users with direct links from the time entered in my app to the corresponding TimeActivity in QBO—is there any way to do so?
The answer to this is that it's not currently possible because there's multiple base URLs (I think they call them "realms") in use for QuickBooks Online (qbo.intuit.com is only one of them). Because you do not receive this information as part of linking to QBO via OAuth, there's unfortunately no way to construct proper links.
Yes, when creating a successful TimeActivity you will receive back an Id, which I assume you are persisting.
That Id can be used to query QBO in a simple GET request.
<baseURL>/company/{companyID}/timeactivity/{timeactivityId}
I'm trying to wrap my head around how to design a RESTful API for creating object graphs. For example, think of an eCommerce API, where resources have the following relationships:
Order (the main object)
Has-many Addresses
Has-many Order Line items (what does the order consist of)
Has-many Payments
Has-many Contact Info
The Order resource usually makes sense along with it's associations. In isolation, it's just a dumb container with no business significance. However, each of the associated objects has a life of it's own and may need to be manipulated independently, eg. editing the shipping address of an order, changing the contact info against an order, removing a line-item from an order after it has been placed, etc.
There are two options for designing the API:
The Order API endpoint intelligently creates itself AND its associated resources by processing "nested resource" in the content sent to POST /orders
The Order resource only creates itself and the client has to make follow-up POST requests to newly created endpoints, like POST /orders/123/addresses, PUT /orders/123/line-items/987, etc.
While the second option is simpler to implement at the server-side, it makes the client do extra work for 80% of the use-cases.
The first option has the following open questions:
How does one communicate the URL for the newly created resource? The Location header can communicate only one URL, however the server would've potentially created multiple resources.
How does one deal with errors? What if one of the associons has an error? Do we reject the entire object graph? How is that error communicated to the client?
What's the RESTful + pragmatic way of dealing with this?
How I handle this is the first way. You should not assume that a client will make all the requests it needs to. Create all the entities on the one request.
Depending on your use case you may also want to enforce an 'all-or-nothing' approach in creating the entities; ie, if something falls, everything rolls back. You can do this by using a transaction on your database (which you also can't do if everything is done through separate requests). Determining if this is the behavior you want is very specific to your situation. For instance, if you are creating an order statement you may which to employ this (you dont want to create an order that's missing items), however if you are uploading photos it may be fine.
For returning the links to the client, I always return a JSON object. You could easily populate this object with links to each of the resources created. This way the client can determine how to behave after a successful post.
Both options can be implemented RESTful. You ask:
How does one communicate the URL for the newly created resource? The Location header can communicate only one URL, however the server would've potentially created multiple resources.
This would be done the same way you communicate linkss to other Resources in the GET case. Use link elements or what ever your method is to embed the URL of a Resource into a Representation.