What verb to use when outside of database land can be argued. I would vote
for POST over PUT just because I tend to default to POST. PUT was there
when I showed up, so I left it. Since the api doesn't wait until the
instances are created to return, we can't really return the instance IDs we
created.
The GET would just return some status?
The PATCH is interesting
The DELETE makes sense to me.
Your use of instances vs instance is interesting. Perhaps we want to
support POST [{profile:"big", instances:2},{profile:"medium", instances:6}]
On Fri, Jun 12, 2015 at 6:23 PM, Will Ochandarena <wochandar...@maprtech.com
> wrote:
> Any reason we need to make it action-based (flex-up/flex-down) rather than
> instance outcome-based? The way i've seen similar things modeled in other
> REST APIs is similar to below. This may also fit better into REST client
> frameworks.
>
> Create - POST /instances/ {"profile" : "zero", "instances" : 2, "delay" :
> 2, "preferredHosts" : ["host1", "host2"]}
> Read - GET /instances/ or GET /instances/<instanceid>
> Update (resize?) - PATCH /instances/<instanceid> {"profile" : "big"}
> Delete - DELETE /instances/<instanceid>
>
> Thoughts?
>
> On Fri, Jun 12, 2015 at 3:07 PM, Jim Klucar <klu...@gmail.com> wrote:
>
> > That is always an issue with parameters in the URL, and there's nothing
> > worse than parameters in the URL and having to put JSON in the body
> because
> > we want to extend it later. Currently flexup takes a JSON blob in the
> body
> > which we could add more to like you showed. I guess the question is if we
> > want to support a quick and dirty flexup api via URL parameters. I
> wouldn't
> > go any further than these parameters, but all this would do at this point
> > is make testing with a curl command easier. Getting rid of it for flexup
> is
> > fine with me.
> >
> > I do like the flexdown/instance/{instance-id} though. We should probably
> do
> > one with flexdown/instance with a json array of instance-ids too though.
> >
> > Also with the parameter verification patch I just submitted, if you ask
> to
> > flexdown 10 instances and you only have 5 running it will just log a
> > warning and kill all 5. Not sure if that is the desired behavior.
> >
> >
> > On Fri, Jun 12, 2015 at 5:12 PM, Santosh Marella <smare...@maprtech.com>
> > wrote:
> >
> > > 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 <klu...@gmail.com> 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 <
> > smare...@maprtech.com>
> > > > 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 <klu...@gmail.com>
> > 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.
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
