HTTP request path parser

Question

I have written a method to tokenize HTTP request paths such as /employee/23/edit:

protected void compile(String path){
    int mark=0;
    for(int i=0; i<path.length(); ++i){
        if(path.charAt(i)==DELIM){
            if(mark!=i)
                tokens.add(path.substring(mark,i));
            mark=i+1;
        }
        else if(path.length()==i+1){
            tokens.add(path.substring(mark,i+1));
        }
    }
}

And a method to tokenize the consumer of these paths such as /employee/[id]/edit:

protected void compile(String path){
    int mark=0;
    boolean wild=false;
    for(int i=0; i<path.length(); ++i){
        if(!wild){
            if(path.charAt(i)==DELIM){
                if(mark!=i)
                    tokens.add(path.substring(mark,i));
                mark=i+1;
            }
            else if(path.length()==i+1){
                tokens.add(path.substring(mark,i+1));
            }
            else if(path.charAt(i)=='['){
                wild=true;
            }
        }
        else if(path.charAt(i)==']'){
            tokens.add("?");
            wild=false;
            mark=i+1;
        }
    }
}

The idea here is that there will be an implicit variable called id with the value 23. However, that isn't here nor there. How does my approach look? Can it be improved? Also: DELIM = '/'.

This is more-or-less an exercise in writing a parser, which is why I didn't use String#split().

Wouldn't String.split() work better for tokenizing a String (download.oracle.com/javase/1.4.2/docs/api/java/lang/…)? — Steven
– Steven, Commented Jan 20, 2011 at 18:23
It looks like anything between the last / and an opening [ will be ignored. Is that intentional? — sepp2k
– sepp2k, Commented Jan 20, 2011 at 18:26
@shambleh: This was more or less an exercise in writing a simple parser. I anticipate it becoming more complicated over time where String#split() wont suffice. — Jeremy
– Jeremy, Commented Jan 20, 2011 at 18:28
It also seems weird to me that you're just discarding the names of the variables like that. Though without knowing how you'll use the result of the compile method, it's hard to say whether it's bad or not. — sepp2k
– sepp2k, Commented Jan 20, 2011 at 18:44
@sepp2k: For sake of posting less code, you don't see anything more than the parsing aspect. I took out the part you are referring to. — Jeremy
– Jeremy, Commented Jan 20, 2011 at 18:54

sepp2k · Accepted Answer · 2011-01-20 18:30:53Z

Your first compile method can be replaced by a single call to String.split.

Assuming the intended behavior for the second compile method is such that "/foo/b[a]r/baz" will compile to {"foo", "?", "baz"}, it can be replaced by a call to split and then iterating over the result and replacing any string the includes square brackets with "?".

If the intended behavior is rather that it will compile to {"foo", "b", "?", "r", "baz"}, you can first replace [anything] by /?/ using String.replace and then use String.split.

Mark Loeser · Accepted Answer · 2011-01-20 19:49:02Z

4

Just as an exercise in making the code easier to read, I'd recommend better variable names. I can figure out what "wild" and "mark" are, but it should be immediately apparent to me so I don't have to spend time trying to figure out what they are.

Also, I'm assuming you are going to eventually handle URLs with "?" and such in them. You may want to consider checking for invalid characters in the URL so you know when you hit the end of the actual request path.

answered Jan 20, 2011 at 19:49

Mark Loeser

1,7631 gold badge14 silver badges15 bronze badges

\$\begingroup\$ I have to disagree about the variable names, unless you can suggest better ones? mark is a perfectly valid in my opinion because it is marking a point in the string. I could change wild to isWild I suppose. As for handling question marks, no, the purpose for the paths with wildcards is to be parsed on the server when the web application starts up. I intend to annotate a method like this: @Get("/employees/[id]"). I am just dealing with paths, not the query string. \$\endgroup\$

Jeremy
– Jeremy

2011-01-20 19:59:53 +00:00
Commented Jan 20, 2011 at 19:59
\$\begingroup\$ Well, 'position' might make the intent clearer than 'mark' :) As for 'wild', a name including 'wildcard' might be easier to understand. \$\endgroup\$

user185
– user185

2011-01-22 17:20:46 +00:00
Commented Jan 22, 2011 at 17:20

Add a comment |

Stack Exchange Network

HTTP request path parser

2 Answers 2

You must log in to answer this question.

Hot Network Questions

HTTP request path parser

2 Answers 2

You must log in to answer this question.

Related

Hot Network Questions