Should we return null and 200 when no records are found?

[Alberto Leal]

Hi,

I've sent a pull request a couple of days applying the same behavior we have for findById, which returns 404 when no records are found through rest:

https://github.com/strongloop/loopback-datasource-juggler/pull/135#issuecomment-46029392

(Without this patch, we get a 200, as status code, and null.)

What is the expected behavior in this scenario?

thanks,

Alberto

--
Alberto Leal
@albertoleal

[Raymond Feng]

I hope it’s not going to be a hot ‘REST’ religious debate :-)

Here is what I have in mind:

1. findById is to get details about a model instance by id and the client has an expectation to find exactly one instance

.

2. findOne is to find the 1st matching model instance based on the query filter. I’m not sure if the client expects 0-1 matching or exact 1. For example, I can use it to find a user by username if it’s unique. 

From node.js API perspective, both methods will callback(null, null) if no matching record is found. So it’s purely how it maps to REST. I would like hear other folks’ opinions as we try to adjust an API behavior.

Thanks,

---

Raymond Feng

Co-Founder and Architect @ StrongLoop, Inc.

StrongLoop makes it easy to develop APIs in Node, plus get DevOps capabilities like monitoring, debugging and clustering.

--
You received this message because you are subscribed to the Google Groups "LoopbackJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loopbackjs+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Guilherme Cirne]

I believe in the principle of least surprise.

To me, in this case, the least surprise is findById and findOne with the same behaviour:

- 200 and the resource when it exists;

- 404 and an empty body when the resource does not exist.

The rationale is that findById is really just a specialization of findOne so having the same behaviour is natural, IMHO.

I find 200 and a body with null (the current implementation) to be ambiguous. Did it find a resource and it has a value of null OR did it not find a resource?

Cheers

[Ritchie Martori]

GET /things/7

Should never return `null`. That isn't useful over rest. So we mapped that result to 404 which is useful.

GET /things/findOne?id=7

Should also never return `null`. It is equally useless over rest. We should map this to 404 as well.

I think what is up for discussion is how we should do that mapping. For now I suggest using exactly what we do now for findById (an afterRest handler).

In strong-remoting (and loopback remote methods) I'd like to make it a bit simpler to express "when I return null, I really mean 404". IMO this is common enough that it should be a simple setting such as: `http.notFound = [null]`. Or calling back with an error which includes a 404 status code. If anyone has a better approach I am all ears.

As far as direction for strong remoting (the module that enables the mapping under discussion) is concerned I'd like to allow users to easily specify opinionated mappings between transports (in this case REST) and function paramters (in this case findOne's callback). You should be able to define the semantics of your API.

Right now we have a mix between defining functions for complex scenarios (which we use to map null to 404) and a JSON DSL that can be used to specify mappings (loopback uses this extensively). I'd like to make this more of a first class feature in loopback 2.0. If anyone has thoughts around this please open an issue in strongloop/strong-remoting.

Thanks,

Ritchie

--

[Alberto Leal]

Ritchie, I agree with you.

Raymond, what do you think?

Thanks,
Alberto