tbh i'm not sure about versioning. I was just trying to suggest that new
routes be formulated this way per the new API guidelines:

GET /foos[?id, name, etc=]
POST /foos
PUT /foos [?id, name, etc=]
DELETE /foos [?id, name, etc=]

instead of the old way:

GET /foos
GET /foos/:id
POST /foos
PUT /foos/:id
DELETE /foos/:id

The difference being the use of query params over route/path params.

Technically, adding new routes does not break old stuff right so i don't
think that warrants a major version roll.

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:

GET /foos[?id, name, etc=]
POST /foos <-- takes in 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...


On Wed, Apr 4, 2018 at 1:55 PM, Robert Butts <robert.o.bu...@gmail.com>

> 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
> >

Reply via email to