4 ms·

>Yes, `api/v1/employees/100` should return a 404, because that path represents the location of a specific entity and that entity does not exist. A GET request

by treis 4y ago

>Yes, `api/v1/employees/100` should return a 404, because that path represents the location of a specific entity and that entity does not exist. A GET request to that path should return the current state of the resource at the path. As you note, the current state of that entity is that it does not exist. Let's look at the spec: >200 OK - The request has succeeded. The information returned with the response is dependent on the method used in the request, for example: > GET an entity corresponding to the requested resource is sent in the response; Did the request succeed? Yes, we found the current state of the entity so we return 200 What do we return? "An entity corresponding to the requested resource". In this case however we want to represent an entity that doesn't exist.

dragonwriter 4y ago
> A GET request to that path should return the current state of the resource at the path There is no resource at the path. > As you note, the current state of that entity is that it does not exist. A thing which does not exist does not have state. Existence (and even moreso non-existence) isn’t a state, existence is logically presupposed in any description of state.
- treis 4y ago
  >existence is logically presupposed in any description of state Then please explain how you can write and I can understand the phrase "A thing which does not exist".
  - dragonwriter 4y ago
    Its convenient linguistic shorthand for a common case which would be more properly be described as “a concept of a thing which does not correspond to any actual thing”. While the equivalent linguistic shorthand has been present in most languages for quite a long time, the recognition that the confusion it can sometimes produce between concepts and concrete things is a category error is, while not nearly as old, also fairly old; it is central to Kant’s argument against the ontological argument for God’s existence, for instance.
    - treis 4y ago
      And why shouldn't we go with the convenient linguistic shorthand instead of the esoteric ontological argument?
      - dragonwriter 4y ago
        > And why shouldn't we go with the convenient linguistic shorthand Who said you shouldn't? The shorthand is convenient. But it doesn't mean what other statements with the same shape mean. A thing which isn't doesn't have a state or representation.
- afiori 4y ago
  `100` could be the employee id more than a name of the employee. So a query for id 100 returns the information associated with that id, nominally that it is currently free and not associated with any employee. Many online REST discussions focus too much on shallow linguistic analogies with verbs/nouns.
  - dragonwriter 4y ago
    > So a query for id 100 returns the information associated with that id, nominally that it is currently free and not associated with any employee If you were doing a static website serving from a file system and said the same thing about a filename as a path component, you'd be seen as mad. But there is no difference when there is an id for a potential employee than a name for a potential file: if no employee/file exists when the server looks for the id/name, the correct result is 404 Not Found. The id isn't the resource, it's part of the path to the resource (and if it is the resource in that URL, you need a different scheme for when you need to find the employee pointed to by the id and not info about the id.)
    - afiori 4y ago
      That is defined by the previous segment of the path. The content of the file `/api/v1/employees/100` need to be defined off-band somehow since you cant actually put an employee on disk. moreover part of REST is that you are not responding with static files by path, but with representations of entities; the question then is whether the entity is the employee or the id. I agree that `/api/v1/employees/100` is not the best name for the id entity, something like `/api/v1/employee-id-status/100` might be more descriptive.

by treis 4y ago

dragonwriter 4y ago

> A GET request to that path should return the current state of the resource at the path There is no resource at the path. > As you note, the current state of that entity is that it does not exist. A thing which does not exist does not have state. Existence (and even moreso non-existence) isn’t a state, existence is logically presupposed in any description of state.

treis 4y ago
>existence is logically presupposed in any description of state Then please explain how you can write and I can understand the phrase "A thing which does not exist".
- dragonwriter 4y ago
  Its convenient linguistic shorthand for a common case which would be more properly be described as “a concept of a thing which does not correspond to any actual thing”. While the equivalent linguistic shorthand has been present in most languages for quite a long time, the recognition that the confusion it can sometimes produce between concepts and concrete things is a category error is, while not nearly as old, also fairly old; it is central to Kant’s argument against the ontological argument for God’s existence, for instance.
  - treis 4y ago
    And why shouldn't we go with the convenient linguistic shorthand instead of the esoteric ontological argument?
    - dragonwriter 4y ago
      > And why shouldn't we go with the convenient linguistic shorthand Who said you shouldn't? The shorthand is convenient. But it doesn't mean what other statements with the same shape mean. A thing which isn't doesn't have a state or representation.
afiori 4y ago
`100` could be the employee id more than a name of the employee. So a query for id 100 returns the information associated with that id, nominally that it is currently free and not associated with any employee. Many online REST discussions focus too much on shallow linguistic analogies with verbs/nouns.
- dragonwriter 4y ago
  > So a query for id 100 returns the information associated with that id, nominally that it is currently free and not associated with any employee If you were doing a static website serving from a file system and said the same thing about a filename as a path component, you'd be seen as mad. But there is no difference when there is an id for a potential employee than a name for a potential file: if no employee/file exists when the server looks for the id/name, the correct result is 404 Not Found. The id isn't the resource, it's part of the path to the resource (and if it is the resource in that URL, you need a different scheme for when you need to find the employee pointed to by the id and not info about the id.)
  - afiori 4y ago
    That is defined by the previous segment of the path. The content of the file `/api/v1/employees/100` need to be defined off-band somehow since you cant actually put an employee on disk. moreover part of REST is that you are not responding with static files by path, but with representations of entities; the question then is whether the entity is the employee or the id. I agree that `/api/v1/employees/100` is not the best name for the id entity, something like `/api/v1/employee-id-status/100` might be more descriptive.