For the future, we could think about adopting that interface as well. We could extend it by a query for names (obviously). I'm thinking about the following extension:
Code: Select all
GET http://host:port/rest/name/name.json
-> returns JSON similar to "name_show"
GET http://host:port/rest/name/name.bin
-> returns the name's value as raw "binary"
GET http://host:port/rest/name/name.hex
-> returns the name's value hex-encoded
Questions:
1) Does this solve (most) of the problems the original REST discussion was about? Is this interface enough to support all or at least the most important use cases?
2) Since names can (and usually even do) contain a "/" character, it may be unnatural to query by the literal names in the REST URI. Should we encode the name instead in some way (hex or urlencode come to mind - they are easy to use from probably almost any programming language)? Or define rules like "the name is everything (including slashes, dots and so on) after "/name/" and before the last "." in the query"? That seems strange and doesn't allow binary names. How is this usually done in REST APIs?