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