RESTful URL design

Question

We have a function to check whether an address is validate.

At first the url is like

/address/validate/{city}/{state}/{zipCode}

But later I thought that all the parameters for address is just one resource. So I changed it to

/address/validate/{city}.{state}.{zipCode}

I'm not sure which one is better, what's your advice?

Answer 1

In this case I would go for /address/validate?city={city}&state={state}&zipcode={zipCode}

Why? Well it is just my opinion. But think of paths (uris) as a unique identifier for a representation. Which usually is a part of your model domain. Since you are not storing (presumably) the result of the validation then just create a validate resource.

Think of it as a method. And the parameters are query-params.

So, doing this, the representation of validate (whether is valid) is modified by the params.

Think in rest as a representations, in your example I guess that /address/ exists as a resource, and it has a representation on your data model. So you can POST , PUT and or GET to create, modify and retrieve.

But if you want a /address/validate this is probably the result of the validation. SO I'd go with my example.

Answer 2

First one. Becourse it is valid android parseable uri

Answer 3

I think the latter is a better option. If a user were later on to validate anyone of the paramaters, and if you add support, it seems more logical to just leave out a param instead of worrying about the order the subpaths are supposed to be in. It ultimately depends on the design of your application as well, as an API design will make more sense for some domains than others. I would add & between the paramaters as well too.

Answer 4

I wouldn't think neither are valid restful URLs.

What your describing can be thought of as "we have a requirement to create an address resource and validate it". Why not just POST to /address which will create an address resource with the given city, state and zipCode as the data passed through the POST. Now in that logic you would validate if the resource can be created. If it can then you would create it and return a unique reference for that resource, which will be used in subsequent requests /address/:id/... . Otherwise if a validation error occurs you would return a HTTP error code 400 Bad Request .

This is probably more 'Restful' in my opinion.