Take for example the following two GET requests with slightly different arguments:
../user/login_at
which returns the last login date of the user, and
../user/login_at?start=2015-05-01&end=2015-05-31
which returns an array of all login dates of the user within May.
Are there any downsides for this API to perform these two slightly different functions?
I could think of,
in the first example the user expecting a string or json Object value to return. But in the second example, the user expecting to return an array.
It may lead the user to create messy if else statement.
It would be better if you rename the endpoint to.
/user/last_login_at
and
/user/login_logs
No. I think they are clear and should be different because they perform different tasks, even if they perform activities for the same entity.
Perhaps create a Boolean parameter, so that you retrieve the last login by:
/user/login_at?last
You effectively then have one endpoint that filters by query string, and could use a call like:
/user/login_at?start=2015-05-01&end=2015-05-31&last
...to get the last login time in May.
There might be some inconvenience in parsing the answer, as already noted by bekicot in his answer:
The problem is that your result has a different structure for the two cases.
Why does it have that gratuitious difference?
Simply make the first query answer with a single-element-array, and all is fine.
Aside from that, there's no problem at all. It's analogous to function overloading in languages like C++, where different overloads (different number and type of parameters) can return different result-types.
It looks fine to me. If you know any prospective users of the API, you could ask them if it would be better to always return an array; with one entry if only the last login of the user is requested; this also means that returning an empty array is a perfectly fine way to tell the client that the user never actually logged in.
The client can then use identical code to process the answer to the point where he/she has an array of objects, typically 1 and sometimes 0 entries in the first case, and any number of entries in the second case.
