search

sideshowcoder / canned

Server to respond with fake API responses, by using a directory of files for finding out what to say!
213 stars 46 forks source link

Windows cannot deal with & and ? in filenames #19

Closed sideshowcoder closed 9 years ago

sideshowcoder commented 10 years ago

When on windows checking out a repository which contains files with ? or & in their names will fail, since they are not valid chars for windows filenames. This is trouble when using get parameters encoded in the filename.

One way to solve this would be to add the parameters like a special comment as StatusCode already is. In this case their is the need to provide a way to have multiple files for the same path then. This could be solved by prefixing the filename with a number 1_search.get.xml would map to /search then.

Maybe this can be extended to be used for post and put body as well.

mulderp commented 10 years ago

Can you explain again how this mapping would work:

1_search.get.xml --> /search
2_search.get.xml -->  ...

Maybe there would be another possibility: Introduce a /search/params directory, and map a file query in that subdirectory to the /search?query=... route.

Well, just loud thinking, alternatively a special config file in the directory might work e.g params.json and define a small mapping there... ok, have to leave again.

sideshowcoder commented 10 years ago

Rather than splitting the params and the contents I would prefer to keep them in the same file so when I have to edit I know only one file changes and everybody knows what is going on. Introducing directories might become confusing since there already is the notion of directories to handle posts/1/comments or alike, having one for params, not sure about that, but maybe we can spike it out and see what sticks.

I have been thinking about the mapping a little more and I think something like 

search.get.xml.1 --> /search&q=foo
search.get.xml.2 --> /search&q=bar

will be more intuitive, because suffixing a file feels more natural than prefixing.

The params would then be stored in the header of the file, currently the header is only used for a status code like //! statusCode: 201 but this can be extended to //! statusCode: 201 query: q=foo&sort=desc or something alike.

mulderp commented 10 years ago

What I like on that header idea, is some kind of "declarative syntax" for matching requests. Separating request/response might be helpful, i.e. spread the rules over 2 lines.