tags:

views:

44

answers:

4
+1  Q: 

RESTful concerns

I have question regarding RESTful resources similar to this other question.

We're also developing an iphone app that will access the REST services but one of the concerns is that the first screen makes a few calls to the service and that it should be just one (A dto of the resources).

I'm trying to keep the service as RESTful as possible so I was wondering how to access it cleaning.

I was thinking of considering the iphone (or any other device) as a resource and that this dto is a property. The URI would be something like this:

example.com/rest/Device/iphone/HomeScreen

Would something like this be acceptable or is there a better solution?

Thanks Tony

+1  A: 

I'd say that if you're able to roll up all the data your wanting to shove over the wire and name it something that makes sense, that might be better than what you currently have.

Whatever you end up calling that structure, I'll call it 'foo', the GET for example.com/rest/foo would return that

I agree that it is important to limit the chattiness of your app since you own both the app and the service and probably nobody else will be consuming your service.

MStodd
A: 

Hello,

The iPhone is like a special client which needs the output formatted in a special way (like AJAX sometimes needs JSON insted of HTML).

So I'd recommend to keep the url as short as possible:

example.com/rest/HomeScreen

Now you have do determine in your controller which format is requested (html, json, iphone). You could do this by determine the user agent or by appending an extension like:

example.com/rest/HomeScreen.iphone
example.com/rest/HomeScreen.html
example.com/rest/HomeScreen.xml

etc.

sled
A: 

I wouldn't design a HomeScreen resource (it feels very front-end specific). What does you HomeScreen display? I rather would expose the model which is displayed on HomeScreen as the HomeScreen model itself.

We have iphone app using REST api which is calling several resources (multiple calls). Still the app feels very quick, because "performance boosters" are used (caching, control over payload size, compression).

Regarding content-negotation I think an interoperable format for iphone is sufficient (json or xml). The mobile device then can render this model how it likes.

manuel aldana
+1  A: 

What you are doing IMHO is perfectly acceptable. The REST principles are much easier to apply when your resources more focused around the requirements of the client UI.

I do exactly the type of thing you are doing:

http://myserver.com/desktop/{dataset}/shell
http://myserver.com/shopclient/{dataset}/login
http://myserver.com/mobile/{dataset}/home
Darrel Miller