-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Buckets in the HTTP API (SOFIE-2795) #1070
feat: Buckets in the HTTP API (SOFIE-2795) #1070
Conversation
…-33/buckets-api-http-release51
…-33/buckets-api-http-release51
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## release51 #1070 +/- ##
=============================================
- Coverage 58.12% 57.80% -0.33%
=============================================
Files 507 509 +2
Lines 81917 82594 +677
Branches 4325 4319 -6
=============================================
+ Hits 47615 47740 +125
- Misses 34254 34802 +548
- Partials 48 52 +4 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see anything here for retrieving the contents of a bucket. Should that be here?
When it comes to exposing the adlibs in the LSG, I would suggest considering grouping the different versions of an adlib up as one document with 'variants'. I am not sure how that will look (or if it will work well), but the way we have multiple documents for each bucket item was a performance problem for us at one point.
…-33/buckets-api-http-release51
…-33/buckets-api-http-release51
@Julusian Those are some very good points about the externalId and variants. Do you agree that when executing a bucket adlib it should also be possible to do so by the
I'm working under the assumption that since regular adlibs can't be retrieved over HTTP either, the LSG will be used for that purpose, but I'm open to adding it if you think that's necessary. |
Makes sense, I haven't looked to closely at the other APIs, so I am fine that this follows what they are doing.
One thing to note here is that the externalId is only guaranteed to be unique within the bucket. So if using this as the id when executing, you will also need to provide the bucket id (ie, a new endpoint will be needed to execute a bucket adlib from this id). Meaning this wouldn't need to be a breaking change, leave the code in the old endpoint to still work with the document id. I don't know if anyone else will disagree with this proposal? But I do think it makes sense to do to avoid clients needing to know how to group up the different versions of an adlib/adlib-action. |
Hey @ianshade ! Let's schedule a session in a few days time to discuss how to progress this PR. (If you haven’t already, please give our contribution guidelines a read.) |
…-33/buckets-api-http-release51
Notes from the discussion Attendees: @nytamin , @Julusian , @mint-dewit , @ianshade
|
…-33/buckets-api-http-release51
…-33/buckets-api-http-release51
Thank you all for your input! I believe I have now addressed all the comments. |
54e9db4
to
a3cf788
Compare
…3/buckets-api-http-release51
I have now addressed the remaining comments, resolved merge conflicts, and fixed a bug that I found (incorrect selectors when fetching buckets). |
This PR is being opened on behalf of TV 2 Norge.
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Exposes existing features regarding Buckets over the HTTP API
What is the current behavior? (You can also link to an open issue here)
Buckets and Bucket AdLib management is only available over DDP. Only execution of bucket adlibs is available over HTTP.
What is the new behavior (if this is a feature change)?
The following features are made available over HTTP:
Other information:
It is assumed that validation of the payload when importing an adlib is performed by the blueprints.
Status