0

According to the RESTful API best practice research I've been doing, a URI should uniquely identify a resource or list of resources. Because of this, I would like to create endpoints that use arbitrary path key/value pairs like:

GET /customers/status/enrolled

instead of like this:

GET /customers?status=enrolled

Similarly, I would like to setup an unlimited number of identity partitions like this:

GET /customers/{attribute1Name}/{attribute1Value}/{attribute2Name}/{attribute2Value

Is it possible with SpringMVC to create a RequestMapping with an arbitrary set of path key/value pairs and with an unlimited number of them?

Cœur
  • 34,719
  • 24
  • 185
  • 251
cosbor11
  • 12,119
  • 9
  • 48
  • 64
  • I can't say for sure, but I'd be surprised it if did. I also don't think what you're trying to accomplish is a good idea - I think you may be misunderstanding "A URI should uniquely identify a resource or list of resources". – Eric Stein Jun 21 '15 at 02:51
  • Thanks for the comments @Eric Stein. Can you elaborate on what makes it "not a good idea"? Let's say that the resource is employees. Attribute1 is region, and attribute2 is status. So the URI would be http://api.mycompany.org/employees/region/west/status/active. Doesn't that URI uniquely identify a a list of resouces? It's a subset group within the hierarchy. – cosbor11 Jun 21 '15 at 07:28
  • You're creating a huge hierarchy of collections rather than a single collection endpoint. This is very non-standard and non-intuitive. Why are you trying to avoid query parameters? They exist for the explicit purpose of filtering a collection, which is what you're trying to do. – Eric Stein Jun 21 '15 at 17:04
  • Hmmm. How should one decide when to use path params instead of query params? It seems like query params should be used only for arguments that support system settings like pagination, sorting, grouping, etc. The goal of Rest is to make predictable endpoints. Wouldn't creating a rule that says path params are for data identification, and query params are for system functionality? – cosbor11 Jun 21 '15 at 17:25
  • REST has nothing to do with predictable endpoints. REST is an architectural style. REST doesn't care about what endpoints look like. Can I suggest doing some more reading, perhaps starting with http://stackoverflow.com/questions/671118/what-exactly-is-restful-programming ? – Eric Stein Jun 21 '15 at 17:48
  • I'm speaking on best practices of REST, not the textbook definition. With any good API, making it predictable is one of your goals. – cosbor11 Jun 21 '15 at 18:06

0 Answers0