REST web services, just for database access only?
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 se开发者_Python百科t 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?
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>
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.
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.
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.
加载中,请稍侯......
精彩评论