t;
> >> >> > While we're on the subject, what does everyone think if we took
> this
> >> one
> >> >> > step further and made routes handle a request payload with one or
> more
> >> >> > items. For example:
> >> >>
os to create
>> >> > PUT /foos <-- takes in an array of foos to update
>> >> > DELETE /foos <-- takes in an array of foos to delete
>> >> >
>> >> > in this scenario, query params only pertain to the GET. The POST, PUT
>> and
>> >> > DELETE rely on the contents of the request json...
>> >> >
>> >> > Jeremy
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Wed, Apr 4, 2018 at 1:55 PM, Robert Butts <
>> robert.o.bu...@gmail.com>
>> >> > wrote:
>> >> >
>> >> >> That document doesn't mention versions, 1.2 vs 1.3 vs 2.0.
>> >> >>
>> >> >> Just to clarify, changing to query parameters breaks compatibility
>> with
>> >> 1.2
>> >> >> and older, so new APIs in that format have to be a new major version,
>> >> i.e.
>> >> >> 2.0, per Semantic Versioning, right?
>> >> >>
>> >> >> On Tue, Apr 3, 2018 at 3:26 PM, Jeremy Mitchell <
>> mitchell...@apache.org
>> >> >
>> >> >> wrote:
>> >> >>
>> >> >>> FYI - I've updated the TO API guidelines to reflect our desire to
>> move
>> >> >> away
>> >> >>> from route/path params and embrace query params in the Golang API.
>> >> >>>
>> >> >>> https://cwiki.apache.org/confluence/display/TC/API+Guidelines
>> >> >>>
>> >> >>> Jeremy
>> >> >>>
>> >> >>
>> >>
>> >>
>>
an array of foos to create
> > >> > PUT /foos <-- takes in an array of foos to update
> > >> > DELETE /foos <-- takes in an array of foos to delete
> > >> >
> > >> > in this scenario, query params only pertain to the GET. The POST,
> PUT
> > and
> > >> > DELETE rely on the contents of the request json...
> > >> >
> > >> > Jeremy
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Wed, Apr 4, 2018 at 1:55 PM, Robert Butts <
> > robert.o.bu...@gmail.com>
> > >> > wrote:
> > >> >
> > >> >> That document doesn't mention versions, 1.2 vs 1.3 vs 2.0.
> > >> >>
> > >> >> Just to clarify, changing to query parameters breaks compatibility
> > with
> > >> 1.2
> > >> >> and older, so new APIs in that format have to be a new major
> version,
> > >> i.e.
> > >> >> 2.0, per Semantic Versioning, right?
> > >> >>
> > >> >> On Tue, Apr 3, 2018 at 3:26 PM, Jeremy Mitchell <
> > mitchell...@apache.org
> > >> >
> > >> >> wrote:
> > >> >>
> > >> >>> FYI - I've updated the TO API guidelines to reflect our desire to
> > move
> > >> >> away
> > >> >>> from route/path params and embrace query params in the Golang API.
> > >> >>>
> > >> >>> https://cwiki.apache.org/confluence/display/TC/API+Guidelines
> > >> >>>
> > >> >>> Jeremy
> > >> >>>
> > >> >>
> > >>
> > >>
> >
>
gt; >
>> > in this scenario, query params only pertain to the GET. The POST, PUT and
>> > DELETE rely on the contents of the request json...
>> >
>> > Jeremy
>> >
>> >
>> >
>> >
>> >
>> >
>> >
&g
gt;
> >
> >
> >
> >
> > On Wed, Apr 4, 2018 at 1:55 PM, Robert Butts <robert.o.bu...@gmail.com>
> > wrote:
> >
> >> That document doesn't mention versions, 1.2 vs 1.3 vs 2.0.
> >>
> >> Just to clarify, changing to query parameters
<-- takes in an array of foos to delete
> > >
> > > in this scenario, query params only pertain to the GET. The POST, PUT
> and
> > > DELETE rely on the contents of the request json...
> > >
> > > Jeremy
> > >
> > >
> > >
> &
he request json...
> >
> > Jeremy
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Wed, Apr 4, 2018 at 1:55 PM, Robert Butts <robert.o.bu...@gmail.com>
> > wrote:
> >
> >> That docum
ent doesn't mention versions, 1.2 vs 1.3 vs 2.0.
>>
>> Just to clarify, changing to query parameters breaks compatibility with 1.2
>> and older, so new APIs in that format have to be a new major version, i.e.
>> 2.0, per Semantic Versioning, right?
>>
>> On Tue,
akes in an array of foos to update
>> > DELETE /foos <-- takes in an array of foos to delete
>> >
>> > in this scenario, query params only pertain to the GET. The POST,
>> PUT and
>> > DELETE rely on the contents of the request json.
> > wrote:
> >
> > > That document doesn't mention versions, 1.2 vs 1.3 vs 2.0.
> > >
> > > Just to clarify, changing to query parameters breaks compatibility
> with
> > 1.2
> > > and older, so new APIs in that format have to be a new major
> version,
> > i.e.
> > > 2.0, per Semantic Versioning, right?
> > >
> > > On Tue, Apr 3, 2018 at 3:26 PM, Jeremy Mitchell <
> mitchell...@apache.org>
> > > wrote:
> > >
> > > > FYI - I've updated the TO API guidelines to reflect our desire
> to move
> > > away
> > > > from route/path params and embrace query params in the Golang
> API.
> > > >
> > > > https://cwiki.apache.org/confluence/display/TC/API+Guidelines
> > > >
> > > > Jeremy
> > > >
> > >
> >
>
>
>
rmat have to be a new major version,
> i.e.
> > 2.0, per Semantic Versioning, right?
> >
> > On Tue, Apr 3, 2018 at 3:26 PM, Jeremy Mitchell <mitchell...@apache.org>
> > wrote:
> >
> > > FYI - I've updated the TO API guidelines to reflect our desire to move
> > away
> > > from route/path params and embrace query params in the Golang API.
> > >
> > > https://cwiki.apache.org/confluence/display/TC/API+Guidelines
> > >
> > > Jeremy
> > >
> >
>
query parameters breaks compatibility with 1.2
> and older, so new APIs in that format have to be a new major version, i.e.
> 2.0, per Semantic Versioning, right?
>
> On Tue, Apr 3, 2018 at 3:26 PM, Jeremy Mitchell <mitchell...@apache.org>
> wrote:
>
> > FYI - I've updat
<mitchell...@apache.org>
wrote:
> FYI - I've updated the TO API guidelines to reflect our desire to move away
> from route/path params and embrace query params in the Golang API.
>
> https://cwiki.apache.org/confluence/display/TC/API+Guidelines
>
> Jeremy
>
FYI - I've updated the TO API guidelines to reflect our desire to move away
from route/path params and embrace query params in the Golang API.
https://cwiki.apache.org/confluence/display/TC/API+Guidelines
Jeremy
14 matches
Mail list logo