400/404 in response to invalid Sps-Execution-Context header

[apitukh]

In what cases do we need to return 400 or 404 status in responses, for example when ID is correct, but Execution Context header is not (i.e. service has resource with this id, but not for given context)?
Links to #92

[travisgosselin]

Specifically in the proposed PR (not moved to discussion), when using Execution Context that is passed to an endpoint like:

GET https://api.com/resources/1
SPS-EXECUTION-CONTEXT: blue

If resource 1 does not exist in that execution context, what should the proper status code be? Does it behave as if the resources does not exist and return a 404. This implies that IDs for the resource are unique only within an execution context, and that the URL is NOT a direct locator or unique address - which I think is problematic for general RESTful API Design.

Alternatively, you could return a 400, which implies the user made a bad request - that resource exists but not in that context. Of course an error message would provide that feedback I imagine.

If I understand correctly the advantage of some endpoints requiring an execution context is to enforce validation, that you don't accidently retrieve a resource from the wrong context and mixup "production" requests from "sandbox" requests?

The core statement from the PR to discuss:

Resources that can store data in multiple Execution Contexts **MUST** result in `400 - Bad Request` if the resource exists but does not have data for the given context.

This pattern as a requirement is pushing it towards a composite key.

[omnipitous]

Hopefully not to muddy the conversation too much but for very specific reasons Execution Context in the service that is driving this conversation right now (Lookup Store) exists at the Fragment layer of the Object Model. We have added Fragment Endpoints in addition to the Object-Level endpoints so technically this question has 2 "Flavors":

1. Fragment Endpoint - Get By Fragment ID - Fragment Exists but is explicitly in wrong Execution Context.
2. Object Endpoint - Get By Object ID - Object Exists but has No fragments in the specified Execution Context.

1 feels more straight-forward than 2. I'm fairly confident 1 should be a 400 Bad Request (With clear human readable / machine parseable error message) as you're providing conflicting data in your request.

2 OTOH EC doesn't exist on the Object Level so technically your Get By ID is "Valid" BUT since no Fragments exist in your provided Execution Context you would get back an Object with 0 Fragments which is technically Not a valid Object. (All Metadata No Data). This feels more like a 404 Not Found? Could in this specific case be a 400 probably depending on interpretation (Since your "Valid Request" is returning an "Bad Response" does that make it a "Bad Request"??

We also talked in the last instance of this conversation about how the Facilitating behavior of Lookup Store *might not be the same as the ODO Bridges sitting between it and the UX. Such as LS could return a 400 but the ODO chooses to present a 404 to the user for "reasons".. in that case I'm not sure how we clarify the Standards here.. ?

[travisgosselin]

Going to discuss further in API Design Review internally about approaches.