I think rather than having an API defined as
"/cluster/flexup/profile/{profile-name}", it's better to define it just as
"/cluster/flexup" and have parameters such as "profile:
<a-value-for-profile-name>" in the JSON payload. The reason is, if the
params are added into the API endpoint, it becomes less flexible to evolve.
For e.g. /cluster/flexup currently can take just "profile" and "instances"
in it's payload, but in the future can optionally take parameters such as
"preferredHosts: [host1, host2, host9]", "delay:
<take_some_sweet_time_before_flexing_up>" etc.Thoughts? Santosh On Fri, Jun 12, 2015 at 1:48 PM, Jim Klucar <[email protected]> wrote: > I thought that might happen. I created a gist here: > https://gist.github.com/klucar/c534d4ecb9f537f9e91e > > And just in case.... > > swagger: '2.0' > info: > version: 0.0.1 > title: Myriad API > description: | > Myriad API description > basePath: /api > schemes: > - http > consumes: > - application/json > - text/plain > produces: > - application/json > - text/plain > paths: > /cluster/flexup: > put: > parameters: > - name: instance > in: body > description: Instance profile and quantity to flex up > schema: > $ref: '#/definitions/FlexUp' > required: true > description: Original Flexup API > responses: > 200: > description: OK > /cluster/flexup/profile/{profile-name}: > put: > parameters: > - name: profile-name > in: path > type: string > description: Instance profile name > description: Flexup a single instance of a specified profile > responses: > 200: > description: OK > /cluster/flexup/profile/{profile-name}/{instances}: > put: > parameters: > - name: profile-name > in: path > type: string > description: Instance profile name > - name: instances > in: path > type: integer > description: Number of instances > description: Flexup a multiple instances of a specified profile > responses: > 200: > description: OK > /cluster/flexdown: > put: > parameters: > - name: instance > in: body > description: Number of instances to flex down > schema: > $ref: '#/definitions/FlexDown' > required: true > description: Original Flexdown API > responses: > 200: > description: OK > /cluster/flexdown/profile/{profile-name}: > put: > parameters: > - name: profile-name > in: path > type: string > description: Instance profile name > description: Flexup a single instance of a specified profile > responses: > 200: > description: OK > /cluster/flexdown/profile/{profile-name}/{instances}: > put: > parameters: > - name: profile-name > in: path > type: string > description: Instance profile name > - name: instances > in: path > type: integer > description: Number of instances > description: Flexdown a multiple instances of a specified profile > responses: > 200: > description: OK > /cluster/flexdown/instance/{instance-id}: > put: > parameters: > - name: instance-id > in: path > type: string > description: Instance profile name > description: Flexup a single instance of a specified profile > responses: > 200: > description: OK > definitions: > FlexUp: > properties: > profile: > type: string > instances: > type: integer > format: int32 > FlexDown: > properties: > instances: > type: integer > format: int32 > > > On Fri, Jun 12, 2015 at 4:31 PM, Santosh Marella <[email protected]> > wrote: > > > Hi Jim, > > > > Did you attach a file? I think the apache mailing list swallowed the > > attachment. Can you please send us the document contents in plain text? > > > > Thanks, > > Santosh > > > > On Fri, Jun 12, 2015 at 1:25 PM, Jim Klucar <[email protected]> wrote: > > > > > This is in regards to https://github.com/mesos/myriad/issues/89 > > > > > > I created a swagger document (attached) of the current flex APIs and > what > > > I propose for the new flex apis. If people like swagger, I can document > > the > > > rest of the API, including the correct response codes. Either way I > think > > > we should discuss what the API should be going forward. > > > > > > Paste the file contents into http://editor.swagger.io/ and you'll get > > > nice HTML to browse. > > > > > > > > > > > >
