From fee2014454dffa387b94b2ce34d3ace050f9cfca Mon Sep 17 00:00:00 2001 From: Max Cherry Date: Sat, 3 Mar 2018 09:16:39 +0200 Subject: [PATCH] Native 1.2: reviewed request types, fixed some godoc comments --- native/request/asset.go | 10 ++++++++-- native/request/image.go | 2 +- native/request/request.go | 5 +++-- 3 files changed, 12 insertions(+), 5 deletions(-) diff --git a/native/request/asset.go b/native/request/asset.go index 47a9a6d..0585930 100644 --- a/native/request/asset.go +++ b/native/request/asset.go @@ -11,7 +11,7 @@ package request // To be more explicit, it is the ID of each asset object that maps the response to the request. // So if a request for a title object is sent with id 1, then the response containing the title should have an id of 1. // -// New in version 1.1 of the spec, there are recommended sizes/lengths/etc with some of the asset types. +// Since version 1.1 of the spec, there are recommended sizes/lengths/etc with some of the asset types. // The goal for asset requirements standardization is to facilitate adoption of native by DSPs by limiting the diverse types/sizes/requirements of assets they must have available to purchase a native ad impression. // While great diversity may exist in publishers, advertisers/DSPs can not be expected to provide infinite headline lengths, thumbnail aspect ratios, etc. // While we have not gone as far as creating a single standard, we've honed in on a few options that cover the most common cases. @@ -50,6 +50,7 @@ type Asset struct { // Description: // Title object for title assets. // See TitleObject definition. + // Each asset object may contain only one of title, img, data or video. Title *Title `json:"title,omitempty"` // Field: @@ -61,6 +62,7 @@ type Asset struct { // Description: // Image object for image assets. // See ImageObject definition. + // Each asset object may contain only one of title, img, data or video. Img *Image `json:"img,omitempty"` // Field: @@ -68,10 +70,13 @@ type Asset struct { // Scope: // optional (each asset object may contain only one of title, img, data or video) // Type: - // object - Video object for video assets. + // object + // Description: + // Video object for video assets. // See the Video request object definition. // Note that in-stream (ie preroll, etc) video ads are not part of Native. // Native ads may contain a video as the ad creative itself. + // Each asset object may contain only one of title, img, data or video. Video *Video `json:"video,omitempty"` // Field: @@ -83,6 +88,7 @@ type Asset struct { // Description: // Data object for brand name, description, ratings, prices etc. // See DataObject definition. + // Each asset object may contain only one of title, img, data or video. Data *Data `json:"data,omitempty"` // Field: diff --git a/native/request/image.go b/native/request/image.go index e938e50..c28864d 100644 --- a/native/request/image.go +++ b/native/request/image.go @@ -89,6 +89,6 @@ type Image struct { // Type: // object // Description: - // This object is a placeholder that may contain custom JSON agreed to by the parties to support flexibility beyond the standard defined in this specification + // This object is a placeholder that may contain custom JSON agreed to by the parties to support flexibility beyond the standard defined in this specification Ext RawJSON `json:"ext,omitempty"` } diff --git a/native/request/request.go b/native/request/request.go index 901d77e..2058218 100644 --- a/native/request/request.go +++ b/native/request/request.go @@ -10,10 +10,11 @@ import "github.com/mxmCherry/openrtb/native" // // The Native Object defines the native advertising opportunity available for bid via this bid request. // It will be included as a JSON-encoded string in the bid request’s imp.native field or as a direct JSON object, depending on the choice of the exchange. -// While OpenRTB 2.3/2.4 supports only JSON-encoded strings, many exchanges have implemented a formal object. +// While OpenRTB 2.x officially supports only JSON-encoded strings, many exchanges have implemented a formal object. // Check with your integration docs. // -// The Default column dictates how optional parameters should be interpreted if explicit values are not provided. +// Note: Prior to VERSION 1.1, the specification could be interpreted as requiring the native request to have a root node with a single field “native” that would contain the object above as its value. +// The Native Markup Request Object specified above is now the root object. type Request struct { // Field: