Resource alias


#1

I have a route defined like this membership/{id}/rewards but also I’d like to access the same resource from membership/{id}/reward

How should I code this in RAML?


#2

Hi @vector, it’s not really clear to me what you want to achieve, can you elaborate a little bit more on that please.


#3

From the use of singular/plural in your resources, I would assume the 2nd url, with just /reward means you want to get a single reward? If that is the case, then it should probably be modeled as /reward/{rewardId} to get just the single reward matching the id. Otherewise, if you really want the /rewards and /reward to both get the same thing, just create another endpoint in the RAML file exactly as you did for /rewards. You can copy/paste it, or possibly set up a trait to reduce the body of the endpoint description.


#4

Yes, I want both routes to get the same resource but I don’t want to copy/paste or define it somewhere else (like a trait)
I was wondering if there’s something like .NET Web API route annotations, like
[Route("membership/{id}/rewards")] [Route("membership/{id}/reward")] public object Get(int id) {}
to define an alias.


#5

Not that I know of. Maybe a Regex pattern? Not sure as I havent tried using something like that. Question though… if you don’t mind answering, why do you want both of those to the same entity? I realize in machine terms the singular vs plural means nothing, but reading it as a human, it would confuse me as to why both singular and plural result in the same resource? Typically the URL includes plurals to specify collections of a resource type. I’d also question returning any arbitrary response type in either case, and instead look to use a schema defined type.


#6

Are you looking for YAML node anchors?

http://www.yaml.org/spec/1.2/spec.html#id2785586


#7

Because there’s an API working using all singular routes. I want to implement plurals without breaking stuff or making a new version just for that.


#8

@Vector Ok… I can understand that. That makes more sense. I am a fan of avoiding version-ing whenever possible. In this case however, as far as I know, you will need to add additional endpoints. Think of it this way… going forward, you would possibly deprecate the old singular formats anyway, and keep the newly added plural versions. Or… you could create a second RAML file with just the newly added plural versions. With RAML 1.0 I believe you can import different RAML files now, so it may work to your advantage to separate them anyway.