All path resources should be followed by a unique identifier for that path resource #44
Unanswered
jsswansonsps
asked this question in
Q&A
Replies: 1 comment 5 replies
-
It looks like the idea doesn't contradict existing standards, at least I would support this approach for some of |
Beta Was this translation helpful? Give feedback.
5 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
// CORRECT
api.spscommerce.com/users/{id}
api.spscommerce.com/users-search
api.spscommerce.com/users-export
In this example the element after the /users resource only has one meaning and returns a consistent payload. The "me" is purely a convenience and still references a single user.
// INCORRECT
api.spscommerce.com/users/{id}
api.spscommerce.com/users/search
api.spscommerce.com/users/export
In this example the element after /users has multiple meanings. It no longer returns a single user and has a different function. Also the payload returned lacks consistency when search and export is used. It no longer returns a single user and has a different function. The element after /users MUST always represent an id for this example.
This would be the preferred approach if there isn't a better way to provide the functionality that is needed.
api.spscommerce.com/users/{id}
api.spscommerce.com/users-search
api.spscommerce.com/users-export
References:
https://www.theserverside.com/opinion/RESTful-parameters-antipattern-considerations-for-queries-paths
Snippet
"If the second path parameter represents a city or a location, it should always represent a city or location. A change like this of an indexed parameter on the fly won't be supported by most RESTful API frameworks."
Beta Was this translation helpful? Give feedback.
All reactions