REST convention for resources with slashes

Is there any REST convention for handleling resources with slashes?

For instance, let's say a normal REST resource works like this:

• /ice cream/chocolate - returns the ingredients of chocolate ice cream
• /ice cream/rocky road - returns the ingredients of rocky road ice cream
• /ice cream/strawberry/banana - returns the stawberry banana ingredients

Only /ice cream/strawbery/banana doesn't quite work because that looks like a resource for strawberry with a subcomponent of banana.... not quite what we're going for.

When you try to escape the '/' with '%2F' many web servers (including glassfish and apache) block this by default as a possible security violation. There are server overrides, but th开发者_C百科en I'd need to get a different team involved... I'd rather just handle it myself.

So what is one with a RESTful mind to do? I can't very well prevent someone from naming their ice cream 'strawberry/banana'.

I was thinking of using some custom escape sequence like stawberry*slash*banana and then force any display component to do the conversion on their end, but I thought others must have faced similar issues, so why not ask for the best practice (or at least for some ideas that make sense)?

Look what stack overflow does with their questions. They add a hyphen instead of the space. You could do the same by replacing your slash with a hyphen. That way you keep the readability of your URI but you avoid the reserved chars.

You don't need the resource name to map exactly to the name of the ice cream because you should never be constructing URIs using the name. If somebody wants to find the strawberry banana ice cream then they should search using some criteria, you display a list of matches with links and they select the strawberry banana. The user doesn't care that you swapped the slash for the hyphen because the name of the ice cream still contains the slash.

if you're setting up the URI then you can decide how to encode the URI. To be truly RESTful the URI doesn't really have to have meaning. /XYZ/12345 could be chocolate while /ABC/zzzzz is rocky road. It's all up to you. You've decided to make your URI have some meaning and now run into this problem with having slashes in the URI but that has nothing to do with REST but with your own URI encoding convention. Actually REST would prefer you list your resources from some base starting point and then users navigate using the URIs you have provided. You could provide a list (in some other format) as:

Chocolate Ice Cream http://base.com/XYZ/12345
Rocky Road Ice Cream http://base.com/ABC/zzzzz
Strawberry/Banana Ice Cream http://base2.com/G789

and the users navigate from there.