3

As we all know a ReST web service cannot hold state - this is a problem for me now when I am considering large database transactions and I wonder if you can help.

My ReST web service has one major role - to do CRUD operations against a database. Problem is if I have to query a table with thousands of rows and send that back to the client as XML - this is not good. It's highly inefficient to keep requesting for thousands of records BUT you cannot do partial transactions (i.e. using ROWNUM keyword in Oracle) with a REST web service. So how do you get round this?

One possible way to get records from a table 100 at a time would be:

http://mywebservice/employees/0/100

I hold state for the last request submitted i.e 100

the next request would be:

http://mywebservice/employees/101/200

and so on. But is this strictly restful?

Vidar
  • 6,548
  • 22
  • 66
  • 96
  • 1
    How is this ORACLE specific? The client has to hold the state and should send data like offset, ordering and number of rows he wanted to be returned. If the client wants all data, you can not do anything about it. So the client should do all the work. Or do I miss something here? Can you post an exact sample? – Christian Dec 09 '10 at 15:39
  • 2
    What is the problem? That the table is big? Or that the returned subset is big? Or that you cannot return subsets of data? – Ronnis Dec 09 '10 at 15:39
  • @Waxolunist - It's not really Oracle specific I just used it as an example. I can agree that the client should do all the work and hold state and form a URL accordingly - but there is a counter argument that the client should not have to know a ton of information to form a valid URL - it should be self linking or else I think you are treading into non restful territory. – Vidar Dec 09 '10 at 16:08
  • @Ronnis - The table has a large amount of data and the returned data will be large as a result. The real problem is to work out how best to perform a request to get subsets of the data. – Vidar Dec 09 '10 at 16:09
  • Its not really a ton of information. But if I look at some REST-based javascript tables, they do all hold the sort order and some other stuff, like position and so on. – Christian Dec 09 '10 at 16:10
  • @Waxolunist - OK, not a ton, but more the ability or know how on constructing URLS should be left to an absolute minimum and that from a particular URL you should be able to "navigate" to any other part of the system without having "inside information" about the system. – Vidar Dec 09 '10 at 16:18
  • Your URLs are absolutely correct. Maybe using url-parameters are an option instead of path parameters. – Christian Dec 09 '10 at 19:20
  • @Waxonlunist - if by parameters you mean "http:\\mywebservice\employees?from=0&to=100" - then I think we have broken a key rule of REST as it has now become RPC style. – Vidar Dec 09 '10 at 19:30
  • @Vidar Query parameters or path parameters makes no different to REST. – Darrel Miller Dec 09 '10 at 20:21

1 Answers1

1

You mentioned CRUD but your example looks like read-action only. Why don't you introduce paging?

# items 0 to 99
GET /employees?page=0&size=100
# items 100 to 199
GET /employees?page=1&size=100

It is not clear which state you mean in your example. Talking about Restful over HTTP api, yes HTTP is itself a stateless protocol, but the overall system surely has a state, which can change over time (e.g. when doing write action á la POST).

Maybe you can give example which write actions (you mentioned transactions) you are trying to expose through Restful api?

manuel aldana
  • 15,650
  • 9
  • 43
  • 50
  • I see you are putting from/to ranges as path-elements (which is a paging concept). Parameters (in this case paging) don't speak against Restful URL over HTTP. Whether to encode this inside a path or parameter is often a matter of taste and standards/common-sense. My thumb of rule is, if it feels like a directory (like subresource) make it a path-element, if not make it parameter. I think 'page=1&size=100' fits more as parameters and is more intuitive as /0/99. – manuel aldana Dec 10 '10 at 18:09