验证代表REST中资源和子资源的输入

Question

I have a resource called user and a sub-resource called images. To access a particular image, the only way to do it is using the URL: /users/{userId}/images/{imageId}.

The database schema is such that one user can have multiple images.

The client sends us inputs for "{userId}" and "{imageId}". I would have to validate these inputs. My question is pertaining to validating the "{imageId}" input. I have two options here:

Option 1: Validate if a particular imageId belongs to that userId. If I see no images for the given userId, then throw an error that "There is no image for the given userId".

Option 2: Validate if the image with the given "{imageId}" exists. Throw an error saying "Image with given imageId does not exist". Then again validate (another DB check) if the given "{imageId}", belongs to that "{userId}".

Of the two options above, which option is the right approach?

Answer 1

I have a resource called user and a sub-resource called images. To access a particular image, the only way to do it is using the URL: /users/{userId}/images/{imageId}. The database schema is such that one user can have multiple images.

I think you misunderstood the URI structure restrictions of REST:

There are no restrictions about how to build URIs.

You can use your own conventions, it does not matter, because the clients are decoupled from the URI structures... For example I can say that my images are under the /images/{imageId} . It is perfectly valid...

You don't have to map resources to entities, and by complex applications you won't be able to do that.

Of the two options above, which option is the right approach?

You can send back 404 with a message, that there is no resource under the URI. Error messages about the URI structure does not mean anything to the client. URIs are opaque to the client.