2

I've been reading up on REST web services and would like to implement a rest service of my own.

All the examples on the internet that I've seen relate to database access. But what I want to achieve has nothing to do with accessing a database.

I want to create a REST service that allows a large string and various other parameters to be passed into a resource and it return a xml result set back. Nothing is created or updated into a database, nothing is retrieved from a database. Its passing data to a complex processing procedure to then return the results.

My problem lies with what VERB do I use?

I feel I should use the GET verb to stay in line with best practices but the query could potentially be very large sometimes and passing this on the querystring is in practical.

This leaves me with POST. This seems to fit what I want to acheive but I think it breaks away from REST best practices again!

Is REST only to be used when wanting to interact with a database?

Should I scrap the idea of using rest and create a SOAP service?

UPDATE my REST service is to analyse articles and return keyword reports for the given article. Given this then the resource is 'keywords', a POST to this will return a full report. I was thinking then of a second uri of keywords/recommended, a POST to this will return a few recommended key phrases of the submitted article. Does this comply with REST?

Stuart Elcocks
  • 23
  • 4
  • Could you be more explicit about your application design, for example how have you broken up your application into verbs and nouns. – WeNeedAnswers Nov 01 '10 at 11:40
  • You should use GET, because GET allows cacheing, and it sounds like the same input to your system will always produce the same response. – AlcubierreDrive Nov 01 '10 at 11:45
  • The protocol does suit db applications really well, but that is because a db automatically describes its resources for you. for example a table could be called people. It is then obvious what the methods do on a simply described entity than a bunch of entities. I would think that if your query-string is getting too large, re-factor your application, look at the data usage and descriptions first. May be a design issue. – WeNeedAnswers Nov 01 '10 at 11:52
  • Now that you have clarified what your actually trying to achieve, use the PUT method, an article is a new resource, therefore you are putting it into your application. Your application has never dealt with this resource so you should not be using POST. Since it is a new resource, you can not query against it using GET, as the application has no clue of what your talking about. – WeNeedAnswers Nov 01 '10 at 12:32
  • @WeNeedAnswers - do you not think that the answer Darrel Miller gave regarding the definition of POST according to HTTP specs, is the correct approach. PUT is meant to be used to update a resource that already exists or is known by the application. In my case the web service will not know anything about the article it needs to process. – Stuart Elcocks Nov 01 '10 at 12:45

4 Answers4

4

REST does not require a database, if fact REST has nothing to do with databases.

The scenario you describe is exactly what POST is intended to do. Quoting from the latest revision of the HTTP specs:

The POST method is used to request that the origin server accept the representation enclosed in the request as data to be processed by the target resource.resource.

You could do something like:

POST /ArticleProcessor
Content-Type: text/plain

to send up your article text, and the response could be:

Status: 200 OK
Content-Type:application/xhtml

<html>
<title>Results of keyword processing</title>
<body>
<a rel="FullReport" href="/reports/2343434/full">Full Report</a>
<a rel="TopKeywords" href="/reports/2343434/top">Top Keywords</a>
</body>
</html>
Darrel Miller
  • 139,164
  • 32
  • 194
  • 243
  • Now that is something I missed, why in all the REST internet postings do they say that POST is intended for CREATE or ADD...this is not the correct definition for POST. – Stuart Elcocks Nov 01 '10 at 11:59
  • @Stuart Because one of the definitions is to do that. Unfortunately RFC2616 highlighted that one and people stop reading at the first paragraph. The updated spec being produced by the IETF httpbis working group has de-emphasized that particular usage to prevent the confusion. – Darrel Miller Nov 01 '10 at 12:02
  • Your answer hear would help a lot of people as the definition of POST is immediatley made clear. POST is NOT just for adding or creating a resource, this is just non sensical! If only the sites I have read over the weekend will update there content! This needs to go viral for all REST enthusiasts. Thanks – Stuart Elcocks Nov 01 '10 at 12:32
  • @Stuart I think that is one of the reasons a bunch of very smart people have spent the last few years re-wording the HTTP spec to make it clearer. You are right though, the amount of mis-information on the web about REST is greater than the good information – Darrel Miller Nov 01 '10 at 13:05
1

Remember that REST, similar to SOAP, XML-RPC etc., only describes an interface, not the implementation of the application providing that interface. There is no reason, why REST should only be used in a CRUD database scenario.

I'd use the following approach to your problem:

Let the client send its data through POST with POST parameters (the "large string and various other parameters") to a generic URI (e. g. http://example.com/processor) and return the URI of a result resource (e. g. http://example.com/results/<unique-id>). The client can now GET the results of the "complex processing procedure" from there.

joschi
  • 12,746
  • 4
  • 44
  • 50
  • I like the idea but, now we enter the realms of state. And I believe that a REST service should be stateless. Storing the result set in a db just so that the GET can be called to retrieve the results is probably the only way to fully comply with REST architecture. Which in my view seems expensive for what I want to achieve! – Stuart Elcocks Nov 01 '10 at 11:56
  • 2
    @Stuart By giving the state a URI, you are making the state into a "Resource" state. That is allowed in REST. Whether you store it on a physical disk or keep it in an in-memory store is completely up to you. – Darrel Miller Nov 01 '10 at 12:06
  • @Stuart, how has this answer helped you? I would love to know, unless I have misread the question :) – WeNeedAnswers Nov 01 '10 at 12:11
  • @WeNeedAnswers - I have added a comment to your answer – Stuart Elcocks Nov 01 '10 at 12:17
0

You can take the "best practice" stuff with a grain of salt. I'm not sure that anyone really cares whether POST affects a database or not, so long as it correctly performs whatever operation you've documented.

As long as your users know what behaviour to expect you'll be fine.

Cameron Skinner
  • 51,692
  • 2
  • 65
  • 86
  • 2
    Changing the meaning of a protocol will loose interoperability. In the case of HTTP it is possible to cache data retrieved by GET. Using POST with the semantics of GET to retrieve data will loose the possibility of caching data. – Martin Liversage Nov 01 '10 at 11:33
  • Ok, thats great, can you point me to ANY examples of a REST service where it doesnt involve a database? – Stuart Elcocks Nov 01 '10 at 11:35
  • Martin, in my case caching the data would not be an issue, it would not affect the 'service' i'm trying to implement. But like you say by using a POST to essentially GET a result set is probably the wrong thing to do? – Stuart Elcocks Nov 01 '10 at 11:37
0

I would stick to REST and if you really have too, use a POST method. No REST isn't just for Databases. It should however be very simple to use without the cruft of SOAP. Many of the tasks that SOAP try to do such as authenticate can be done over straight http. The idea is that REST is light and responsive and easy to understand and use. REST I would describe as a conversation with an elderly aunt who keeps forgetting who you are. Perhaps when you query your REST application, you may need to break it down into Nouns and Verbs, for example a query against a person resource or a place resource, instead of trying to query place and person at the same time, split the two and ask each resource your query. It does make the protocol chatty doing it this way, but if your really concerned about network traffic then I would go with XML-RPC or SOAP.

WeNeedAnswers
  • 4,620
  • 2
  • 32
  • 47
  • Thanks, my service is to analyse articles and return keyword reports for the given article. Given this then the resource is 'keywords', a post to this will return a full report. I was thinking then of a second uri of keywords/recommended to return a few recommended key phrases of the submitted article. Does this comply with REST? – Stuart Elcocks Nov 01 '10 at 11:46
  • Wouldn't the resource be Articles, and the query would be against this Article resource, think of the relationship between the two, an Article can have many keywords. Example, http://someplace.com/Articles?Full=No , would bring back a list of all articles in abbreviated form, whilst http://someplace.com/Articles?ID=1234 would bring back articles (should only be one :)) fully with all the keywords and data that relates to it. – WeNeedAnswers Nov 01 '10 at 12:02
  • I would further this example by saying that to query articles with certain keywords you could then go on and say someplace.com/Articles?keywords=one,two,three,four,five,six,seven,eight etc. all the other attributes that you design can then be done around this for example, Full=No, MaxReturn=400 etc – WeNeedAnswers Nov 01 '10 at 12:06
  • @WeNeedAnswers - I don't think my resource is 'article', your right, an article can have many keywords. But my service does not store articles, it takes a POSTED article and processes it to return keywords. Your examples would be correct if I wanted a service that interogated an article db for example and wanted to run queries against it. – Stuart Elcocks Nov 01 '10 at 12:16
  • If your posting a new Article, you should be using the PUT method. The return can come back as a HTTP packet with the keywords in the Content. – WeNeedAnswers Nov 01 '10 at 12:30
  • @WeNeedAnswers `If you're posting a new Article, you should be using the PUT method` Huh? Can you explain what you mean? – Darrel Miller Nov 01 '10 at 13:16
  • There are four HTTP methods GET, POST, PUT and DELETE. PUT is for new stuff, usual creating new articles. In this case your not actually storing the article per say but you are asking for service on a new and unknown entity. Since the entitly is unknown and your not enquiring or updating a known entity, then I would suggest using the PUT method. – WeNeedAnswers Nov 01 '10 at 13:24
  • @WeNeedAnswers PUT is for storing documents on an origin server. After you PUT, you would normally expect to be able to GET from that URI and retrieve a representation. The OP has no need to store his document, he simply needs to process it. Now because he wants to have two distinct types of results then it is better to have the processing generate two resources that are linked to in the response from the POST. I don't see how using PUT in this scenario comes close to solving the problem. – Darrel Miller Nov 01 '10 at 14:27
  • looks to me if your getting keywords back on a second call, you must store the original Article with keywords, else what your referencing, fresh air? – WeNeedAnswers Nov 01 '10 at 16:36
  • @WeNeedAnswers I can store the 500bytes needed to list the top 10 keywords as a separate resource versus storing the 150MB article. – Darrel Miller Nov 01 '10 at 17:54
  • Yes I understand what your saying, but surely the keywords in your system becomes the article/report artefact and not a report. I take it you store the original address of the document. I would imagine that you would store ID, URL, Keywords in an entity of some kind. When I say use PUT this is what your putting in the system, a condensed version of the article your uploading. I don't think that there is any rule being broken in storing a condensed version of an article that does not represent the original verbatim , at least not what I am aware of. – WeNeedAnswers Nov 01 '10 at 21:23
  • I don't quite understand the recommended function, but I would imagine that this would be an attribute of the Articles URL such as someaddress.com/Article?ID=1234?Recommended=Yes&Condensed=true. – WeNeedAnswers Nov 01 '10 at 21:26