yes -- that's really what I meant. Import/Export should not be a separate operation as documented here: https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/default_profiles.html?highlight=import, but should be part of the "normal" API. The default profile files we keep in http://trafficcontrol.apache.org/downloads/profiles/ are in the format I'm describing. They should be in the more standard form and should associate all parameters in the file with the profile.
The Go `POST api/1.3/profiles` endpoint already loads the parameters into memory, but ignores the parameters list. -dan On Mon, Sep 17, 2018 at 9:58 AM Jeremy Mitchell <[email protected]> wrote: > Maybe this is what Dan said but imo there should be no import/export > endpoints but these should do the job: > > GET /api/*/profiles/:id <-- this is essentially an export. it gives you the > json of a profile (along with all the parameters). save the json to a file > and you've essentially exported the profile. > POST /api/*/profiles <-- this is how you create profiles. if you supply > parameters as well you've essentially done an import. > > jeremy > > > > On Mon, Sep 17, 2018 at 9:16 AM Robert Butts <[email protected]> wrote: > > > Can you clarify, are you referring to `/profile/import` and > > `/profile/:id/export`? Or `/api/$version/profiles/:id/export` and > > `/api/$version/profiles/import`? > > > > We should definitely deprecate and remove the non-API endpoints. But IMO > we > > need to keep a way to create and get an entire profile, with parameters, > in > > a single request. Users shouldn't have to make a dozen requests to import > > and export a profile. > > > > Also +1 on changing them to real booleans (not sure if the api > > export/import is, they appear to be undocumented). Though we can't break > > the current API; we could make the POST accept either, but the GET would > > have to be a new endpoint I think. > > > > > > On Sat, Sep 15, 2018 at 3:15 PM Dan Kirkwood <[email protected]> wrote: > > > > > I’d like to propose deprecating the import/export format of profiles. > The > > > current format (Perl-based) is inconsistent with the standard POST > > > api/x.x/profiles format. Import/Export can/should be done using the > same > > > API. Traffic Portal Import should use the standard API endpoint. > > > > > > Import/export (shown below) has this form which includes the "profile" > > key > > > at the top level. The "secure" option in the "parameters" secion uses > a > > > 0/1 rather than a boolean true/false. These 2 things make it > > inconsistent. > > > > > > Opinions are welcome... > > > > > > Dan > > > > > > { > > > "profile": { > > > "name": "myname", > > > ... > > > }, > > > "parameters": [ > > > { > > > "name": "foo", > > > "secure": 0, > > > ... > > > ] > > > } > > > > > >
