Web applications with web-service API access

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Web applications with web-service API access

Post by Chris Corbyn »

I'm building an iPhone client for an existing web application and trying to decide how best to go about the client-server communication. Right now the application is tightly bound to the assumption it is being accessed via a web browser using HTML/Forms.

I don't really have any experience with REST, XMLRPC or SOAP, though I have used SOAP (on the client side) for some third party web services.

Does anyone have any pointers on what considerations I might need to make, and which of REST, SOAP or XMLPC make the most sense for something like an iPhone client (native) to interface with a remote service?

My understanding of REST is that the client has to have quite a solid understanding of the data it's working with (it's doesn't deal with encapsulation) and the server's handling of the requests from the client isn't particularly clever (it just does as it's told). I'm thinking that this makes REST a less ideal candidate, but somebody correct me if I'm wrong. REST is more about transferring raw data between the server and the client, than it is about making remote method calls on the model.

As for SOAP, while I'm sure I can translate more or less any object-oriented model into a service accessed over SOAP, it's hella tedious and bloated.

XMLRPC... I'm not familiar with in the slightest.

Basically, I want my iPhone client to be able to send requests to the server and receive responses that it is able to translate into client-side model changes, but I don't want the client to have an intimate knowledge of how to model is implemented on the server.

The other thing I'm thinking about is how to centralise logic which changes the model (on the server). Right now controller actions handle form submissions. If I had a web-service acrhitecture available, it would be great to delegate such logic to the corresponding action on the web service. I'm hoping that this sort of indirection could promote a thin controller design as a side-effect.

Anybody got experience with exposing a web application's features over some sort of service API as well as via a GUI presented by a web browser?

Say for example our web application is a forum. In our web application we might have a PostController which handles creating posts:

Code: Select all

class PostController ... {
  function createPost() {
  }
  
  function deletePost() {
  }
  
  function movePost() {
  }
}
These actions expect form data and return HTML. I need an equivalent set of actions that are accessed not via a web browser, but by sending XML/JSON to the server and receiving XML/JSON as a response. But I don't want to duplicate too much functionality. My thinking right now is that in the createPost() action that deals with form input, it takes the request data, turns it into XML/JSON and invokes the call on the web service (ideally without the HTTP overhead), interprets and XML/JSON response from the service and presents HTML to the user.

Am I thinking the right way about this? Are there any abstraction libraries available that will help me with this?
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Re: Web applications with web-service API access

Post by Chris Corbyn »

So it seems my ideas about REST were more misconceptions really and in fact, REST would make a good candidate for this, possibly combined with something like XML-RPC.

I just need to think more about the way I abstract this :)
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Web applications with web-service API access

Post by Christopher »

REST is one of those confusing terms that means a couple things. I think the essence of it, as opposed to XML-RPC or SOAP or using sessions in PHP, is that with REST the state information is contained in the URI and the resource returned by the URI. There is not behind the scenes information held over multiple requests. I am not sure if that help you decide what to use. XML-RPC is lighter weight and less full featured than SOAP but they do essentially the same thing. REST URIs can return XML which is different than XML-RPC.
(#10850)
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Re: Web applications with web-service API access

Post by Chris Corbyn »

I'm also investigating JSON-RPC. I think I'd prefer using JSON over XML.

Most likely I'll go with REST after a little more research, since the nature of the application does require full transfer of data from the server to the client in order to display detailed information to the user. The only thing I'm not clear on right now with REST, is how to restrict access to certain resources/operations. Say for example user A should be able to delete a post at http://rest.myapp.com/posts/123 by sending a DELETE request, but user B should not be permitted to do that. From what I can tell, this goes against RESTful principles since any URL should always return a resource.

I'm thinking perhaps that each request is signed in some way on a per-user basis.

EDIT | Or even I should stop over-thinking the authentication issues and use standard HTTP authentication.
User avatar
inghamn
Forum Contributor
Posts: 174
Joined: Mon Apr 16, 2007 10:33 am
Location: Bloomington, IN, USA

Re: Web applications with web-service API access

Post by inghamn »

All of my web applications are also services. All clients, whether they're desktop browsers, or AJAX calls , or mobile phones, or whatever.....they all do the same GET, POST request. So, really a Controller establishes an expectation of fields it expects to be POSTed.

The response it creates is a Template. Templates are view layouts, but also have a specified output format (HTML, RSS, JSON, XML, etc.) The controller creates the template and chooses sets the appropriate output format for the Template (HTML is just the default).

All of the view scripts (I call 'em Blocks) are partials, and are organized by output format. Each output format is a collection of Blocks. It is expected that the directory names and filenames for each output format collection are the same. That way, the controller just adds the blocks to the template, sets the appropriate output format, and tells the Template to render.

The last challenge is to decide how to determine which output format to use. The choosing of output format is done per-controller, and can be different from application to application, depending on the type of clients that are expected to be using the application. Sometimes, I might use browser detection, sometimes, I have the clients ask for an output explicitly, sometimes I look at the format of the POST.

Anyway, it's the model that works well for our stuff. I've had several successful web applications that are also web services in the past two years with this model. It makes it very easy to tie all the applications together using the web services.

Since all the URLs are the same, you can browse the HTML version to find the screen of data you want, or the controller you need to post to. Then you can write a client to use that URL, and ask for the output format that best serves your needs.
User avatar
inghamn
Forum Contributor
Posts: 174
Joined: Mon Apr 16, 2007 10:33 am
Location: Bloomington, IN, USA

Re: Web applications with web-service API access

Post by inghamn »

If you're using REST style, it's appropriate to send a simple 403 Forbidden if user B is not allowed to delete something.
Theory?
Forum Contributor
Posts: 138
Joined: Wed Apr 11, 2007 10:43 am

Re: Web applications with web-service API access

Post by Theory? »

My friend who's making an app told me that XML-RPC is the easiest way to make calls using the iPhone/Cocoa API.

He also told me programming in Objective-C is like unlearning everything you've ever known about how to program, so take that first part with a grain of salt.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Re: Web applications with web-service API access

Post by Jenk »

XML-RPC is horrid, in fact only SOAP is worse.

Go for REST. It's easy stuff, and (for once) doesn't use an arbitrary bloated protocol - it uses HTTP for what it was designed for in the first place.

Use standard HTTP authentication, and then of course your usual HTTP requests.. GET, POST, DELETE, PUT, etc.

Just remember it is a stateless protocol though!
Post Reply