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?

I think it's cleaner to separate it with forward slashes. You probably had to split the parameters yourself with the periods, right? — 0x1F602, Sep 21 '12 at 07:59
This may help http://stackoverflow.com/questions/4024271/rest-api-best-practices-where-to-put-parameters — RNJ, Sep 21 '12 at 09:32

ssedano · Accepted Answer · 2012-09-21T09:29:48.687

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.

/address/ is not exists as a resource for this API, I just use it as namespace since we may have other validation. I use this API to validate address before user submit a form. — yuyue007, Sep 21 '12 at 09:06
That's a valid approach. What don't you like about the params? — ssedano, Sep 21 '12 at 09:27

score 0 · Answer 2 · answered Sep 21 '12 at 08:00

0

First one. Becourse it is valid android parseable uri

answered Sep 21 '12 at 08:00

Artem Zelinskiy

2,201
16
19

score 0 · Answer 3 · answered Sep 21 '12 at 08:02

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.

score 0 · Answer 4 · answered Sep 21 '12 at 08:23

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.

RESTful URL design

4 Answers4