GET /teams/search?homecity=los+angeles Wouldn't this be: GET /teams/los+angeles We could have query-able attributes, this is where I think OPTION verb should

GET /teams/search?homecity=los+angeles Wouldn't this be: GET /teams/los+angeles We could have query-able attributes, this is where I think OPTION verb should come into play. So I would OPTION /teams. This returns some JSON with the meta information about the collection, for instance: `{key :'wins', type: 'string', description: 'some api description', sortable => true, filter: true, group_by: false }`, this should probably hint at the abilities of the attribute (sortable/filter/group_by). This really raises the question of what is a good querying api for collections? I think our answer may be in the form SQL-like interface. GET /teams?wins[gt]=1&losses[gt]=1&wins[sort]=desc&limit=10&offset=0 SELECT * FROM teams WHERE wins > 1 AND losses gt > 1 ORDER BY wins LIMIT 10 OFFSET 0 So what about support ORs or Unions and Joins? Well, ORs are simple they could act like a named scope. GET /teams?wins_or_losses[gt]=1&wins[sort]=desc&limit=10&offset=0 SELECT * FROM teams WHERE (wins > 1 OR losses gt > 1) ORDER BY wins LIMIT 10 OFFSET 0 What about a Union or Join? These should be handled by a new endpoint (joins) or avoided by querying individual collections (unions).