> If it’s not REST then shouldn’t the url be /api/v1/employees?id=1000 instead of encoding the employee id in the URL?
The query portion of a URL is, in fact, part of the URL, so that is encoding the employee id in the URL, and REST doesn’t care about how URLs are constructed, in the first place (in fact, excessive concerns about out-of-band knowledge about how URLs are constructed mostly are a sign of not doing HATEOAS, in contravention of the REST architectural style.)
Yes I used the wrong word. I meant "instead of encoding the employee id in the path?"
And instead of "if its not rest" I meant (in the context of the article) "if it's HTTP RPC" because the author clarified that they were talking about RPC rather than REST.
Remote Procedure Calls typically identify "endpoints" such that a specification of the endpoints could be compiled into a host language's function-calls. The logical way to do that with HTTP is to have a path be the function, and HTTP parameters (whether url or posted) be the parameters of the function.
Using a URL that has both a resource ID encoded in the path and also query parameters is a mixture of REST and RPC. Since the example given in the article does not show parameters, I think it is reasonable to call it REST, as many other commenters here have inferred. The author claiming it is RPC doesn't jive with my expectations for RPC.
Maybe I'm just complaining about calling it RPC. If it's neither RPC nor REST then it's just some random mismash of HTTP-ish stuff, and I don't think that's a particularly strong argument for "things should be done like this".
The query portion of a URL is, in fact, part of the URL, so that is encoding the employee id in the URL, and REST doesn’t care about how URLs are constructed, in the first place (in fact, excessive concerns about out-of-band knowledge about how URLs are constructed mostly are a sign of not doing HATEOAS, in contravention of the REST architectural style.)