.json in the resource identifier? "Verbs are bad", except when it's "search"? /v1/dogs/molly vs. /v2/dogs/molly ?
Colour me unconvinced! I don't really see how promoting this hacky form of REST moves us forward.
Colour me unconvinced! I don't really see how promoting this hacky form of REST moves us forward.
Search is a service, not a part of a resource. Whether a seperate search service aggregating all different REST resources is supplied or not is irrelevant in the example case as resource collections can be filtered, which the article highlights (the colour= parameter), for a dogs resource, or a phonebook resource etc. filtering on attributes (which can use wildcards or regexes as seen fit to do so) provides the necessary functionality anyway. Search is a diversion in these cases.
Go versionless.
Get rid of .json? Make it optional sure, but allow it if the client wants to be specific. Seems like a good feature in that sense (optional with a good default).
I agree that search should not be a resource, but perhaps a parameter for filtering in addition to explicitly named param filters.
Thanks for sharing your thoughts on it.