>
> where do you get random-ish hashes today? you mean the api gw integration?


yes, as an example. the bluemix api gateway introduces an extra level of
management. if component C1 exports an action, then, to import that
endpoint into component C2 (e.g. my web front end) C1's deployment needs to
store its endpoint routes in some sort of registry, so that C2's deployment
can point to the right place.

with the proposed "web" approach, templatization is straightforward:
https://{APIHOST}/{NAMESPACE}/experimental/web/actions/foo

thus, C2 doesn't need any explicit dependence on C1's deployment step.
rather, as an overall deployment of the application, i know the values of
those two variables (e.g. i'm deploying to the London-Production routes),
which breaks the C1-C2 dependence.

On Fri, Jan 13, 2017 at 2:54 AM, Michael M Behrendt <
michaelbehre...@de.ibm.com> wrote:

> > i like that this gives me a stable/predictable route, so that i don't
> have
> to keep around a registry of endpoints in my deployment scripts -- as i
> would if the routes were exposed with a random-ish hash in them.
>
> where do you get random-ish hashes today? you mean the api gw integration?
> If so, I agree that is sub-optimal and should be addressed there as well.
>
>
>
>
> From:   Nick Mitchell <moose...@gmail.com>
> To:     dev@openwhisk.apache.org
> Date:   01/13/2017 12:21 AM
> Subject:        Re: Allow actions to be accessible from a web browser
>
>
>
> i like that this gives me a stable/predictable route, so that i don't have
> to keep around a registry of endpoints in my deployment scripts -- as i
> would if the routes were exposed with a random-ish hash in them.
>
> and i like the idea of a simple way of supporting client applications that
> doesn't require an extra step in deployment scripts. i.e. i just tack a
> `-a
> export true` on to the create/update steps.
>
> i also like the ability to do simple projections, thus avoiding the need
> for `jq` postprocessing. if i project a field, do i also have to type it,
> e.g. /field/x/int? or are the mime types only needed when you want to
> force
> a non-default interpretation?
>
> using mime types to request a particular response header is pretty
> awesome!
> though perhaps its use may be somewhat constrained (until we have
> streaming?) by any payload limitations a whisk installation might have in
> place.
>
> On Thu, Jan 12, 2017 at 5:51 PM, Markus Thömmes <markusthoem...@me.com>
> wrote:
>
> > Haven't looked at the implementation yet but I really dig the idea!
> >
> > Are query parameters forwarded to the action as well?
> >
> > - mt
> >
> > Von meinem iPhone gesendet
> >
> > > Am 12.01.2017 um 23:44 schrieb Rodric Rabbah <rod...@gmail.com>:
> > >
> > > I just opened a pull request to allow actions to be accessible viaa
> web
> > > browser. Action invokes this way are anonymous in that the caller is
> not
> > > authenticated. The intended action must be named in the path as a
> fully
> > > qualified name as in
> > > /experimental/web/some-namespace/some-package/some-action. The package
> > is
> > > optional in that the action may be in the default package. In which
> case,
> > > the string "default" must be used.
> > >
> > > If the action doesn't exist (or the namespace is not valid) a
> BadRequest
> > is
> > > generated. Optionally, the result form the action may be projected
> based
> > on
> > > a named property. As in
> > >
> /experimental/web/some-namespace/some-package/some-action/some-property.
> > If
> > > the property
> > > does not exist in the result then a BadRequest is generated. By
> > convention,
> > > the "html" property will attempt to respond with media type
> "text/html".
> > >
> > > Actions may be exposed to this web proxy by adding an annotation
> > ("export"
> > > -> true).
> > > Demo video https://ibm.box.com/s/5c6ignvejihbai3f59uvqcxee9etf0lf.
> > >
> > > Feedback solicited and welcomed.
> > >
> > > -r
> >
>
>
>
>
>

Reply via email to