Article: Addressing Doubts about REST

| by Floyd Marinescu Follow 38 Followers on Mar 20, 2008. Estimated reading time: less than one minute |
After his first traffic-record setting article, a brief introduction to REST, Stefan Tilkov has written another article attempting to addresses the 10 of the most common doubts people have about REST when they start exploring it, especially if they have a strong background in the architectural approach behind SOAP/WSDL-based Web services.

Read Addressing Doubts About Rest.

The ten doubts Stefan addresses include:

1. REST may be usable for CRUD, but not for “real” business logic
2. There is no formal contract/no description language
3. Who would actually want to expose so much of their application’s implementation internals?
4. REST works with HTTP only, it’s not transport protocol independent
5. There is no practical, clear & consistent guidance on how to design RESTful applications
6. REST does not support transactions
7. REST is unreliable
8. No pub/sub support   
9. No asynchronous interactions
10. Lack of tools

Stefan Tilkov is the lead editor of InfoQ’s SOA community and co-founder, principal consultant and chief RESTafarian of Germany/Switzerland-based innoQ.

What's your take on the 10 doubts?

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Security? by Bernd Schuller

In the WS-* space a lot of options are available for building secure applications. How to realise message encryption, signing, trust delegation etc in a pure REST way?

Re: Security? by Bernd Schuller

should read the conclusion as well before commenting :-)

Re: Security? by Arjen Poutsma

When using XML payloads, the same standards that make up WS-Security (XML-DSIG and XML-Enc) are still available to you.

Re: Security? by Jean-Jacques Dubray


don't you need an "envelope" mechanism to be able to convey the tokens? Security is not just about encryption and signature, authentication, authorization, user identity propagation are difficult to achieve without an envelope.

Resource transformations by Bruno Luiz Pereira da Silva

Something I'd like to see more discussions is Resource Transformations. When you're developing RESTFul services that go somewhat beyond CRUD, you might have several resource transformations.

When a given resouce changes to or from some state, there might be transformations on other resources. For example, let's think of some Amazon sales process where you have Item and Order resources and several related resources like billing and logistics stuff. When the user pays for the Order, some transformation in billing resources would apply a transformation to the Order resource, changing its state to "paid"

When the Order resource has its state changed to "paid", we could have transformations applied to logistics resources, telling the delivery system to deliver the order.

This kind of resource transformations appear a lot when you're developing RESTFul services that are more than CRUD. I think a very good approach to solve this is using finite state machines, defining what resource states we have and what happens in every meaningful state transition.

I'd like to see more discussion about this kind of things, because resource transformations might be very tricky, and complex RESTFul services definitely need them.

Re: Security? by Ian Hlavats


don't you need an "envelope" mechanism to be able to convey the tokens? Security is not just about encryption and signature, authentication, authorization, user identity propagation are difficult to achieve without an envelope.

HTTP provides the envelope mechanism. It defines authorization/authentication headers and status codes for this purpose. Cookies can be used to propagate user identity tokens.

Re: Security? by Jean-Jacques Dubray


sorry, I thought the question was WS-Security. I did not know that the HTTP envelope was compatible with WS-Security nor supported as many different authentication mechanisms, let alone trust federation.

Re: Security? by Jens Goldhammer

The problem is that you have to implement all this kind of stuff for your own. In Axis2 you can activate it by writing a few lines of code...

Re: Security? by Ian Hlavats


sorry, I thought the question was WS-Security. I did not know that the HTTP envelope was compatible with WS-Security nor supported as many different authentication mechanisms, let alone trust federation.

You are correct Jean-Jacques. HTTP security is not as sophisticated as WS-Security, but its basic features (encryption, certificates, authentication, authorization, etc.) could still meet the security needs of some systems.

Plus, HTTP security is extensible:

The HTTP protocol does not restrict applications to this simple challenge-response mechanism for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, these additional mechanisms are not defined by this specification. (HTTP specification)

It would be interesting to see the WS-Security stickers ported to HTTP headers (as suggested by Richardson and Ruby in the RESTful Web Services book).

Thanks for the sharing by Yuen Chi Lian

Agreed. Nothing is perfect for every or even a single scenario.

At least, this article points out that there's always a workaround to a limitation. It's up to how you explore within a given scope.

- yc

Nice. by Zubin Wadia

The Amazon approach is interesting:


Zubin Wadia
"Business Acceleration through Process Automation."

Religious Issue? by Victor Volle

The REST vs. WS debate is now taking some years. This seems strange.
So perhaps instead of putting forward (mostly) the same (refined) arguments
again and again, we should ask ourselves: why? If two parties are disputing
for a long time, they either have completely different viewpoints with
regard to some central _values_ or they simply misunderstand each other.

I think, both is the case. And I think the central issue is API design.
Do you think more about things or what you can do with these things -- i.e. things or verbs.
That's it. That's it? Let me try to explain.

If you come from a business process view, or from a library design view, you
probably are used to think APIs should contain methods like

(a) updatePerson()
(b) retrievePerson()
(c) findPerson()

but this kind of CRUD methods, you could quite simply map to their RESTful equivalents.
But what about

(d) scoreCustomerMortgageRisk(customerId)
// i.e. the customer has send in a mortgage application,
// that should now be "scored" to decide if we can offer
// him a credit contract

(e) promoteToCustomer(personId)
// a person that is in our system, will now become a
// customer (an account will be opend, etc.)

(f) calculateNetInterestRate(credit)

No doubt, you can map these to some RESTful services. (e) might be a PUT (or is it a POST?) of the
Person to a CustomerCollection-Resource (Thanks to Stefan Tilkov, for explaining this to me quite some time ago). And sure in both cases you need a human readable documentation.

But what is more natural to you? If you say "promotePersonToCustomer" you would probably prefer
the WS-Stack and if you think a simple PUT of a Resource is more natural and web-like, you probably
prefer RESTful services.

But please, please do not try to convince me that WS are an abuse of HTTP. If it helps me to achieve
a business goal with less effort (in the long run) then, please, let me use whatever I like.
If using my nose to press keys on my keyboard works faster for me, so why not?
"Abusing" sounds so childish, like I am playing a game with your toy that you never thought of before.

And the WS folks: please do not try to convince me that WSDL and XML-Schema are a good idea.
WSDL is a mess and XML-Schema ain't much better.

And some REST proponents seem to insist that


is so much better (web-like, or whatever) than


Less coupling? More interface stability?
Because of the indirection that forces me to map this URL to a method invocation?
Sorry, I don't get it. Whether I do the indirection by mapping the URL to a method, or
I change the method implementation to call another method ... what's the difference?

The only are where REST has an advantage is interface versioning. Because there is no
coupling of XML to a Schema, I can much easier add elements and attributes to my
XML responses than with XML Schema. But if I rename, remove or otherwise alter my XML,
I have the same problems as with XML Schema. Perhaps even more so as long as I do
not have a (formal) description of my XML that I could easily compare between to versions.

So my conclusion is: Use whatever helps you to achieve your goals. And if your developers
are more accustomed to one or the other, that should influence your decision to some degree.
If your services are only used inside your company, if your servcies just wrap an existing API,
you probably shouldn't use REST. If you are a big company, that offers services over the web
and you want to attract many people to use your services (include them in their own applications,
mash-ups, etc.) REST is often much simpler to use.

But don't believe either side, if they are telling you: theirs is the only way (sounds much
preachy to me).

Re: Religious Issue? by Stefan Tilkov

Victor, would you consider using a RDBMS and then defining a single table only, with two columns, "id" and "content" (the latter a BLOB) an abuse of the RDB?

Re: Religious Issue? by Victor Volle


yes, I would (but I have seen a system, where the RDB was only used as a Cache for some mainframe using only key-value-pairs as data structure -- and they were so proud that they were now using a DB).

But I am not sure that your analogy really fits. An RDB seems to be much more complicated than HTTP to me. But, okay "Übertreibung macht anschaulich" (hyperbole makes colorful).

When I am using HTTP for REST, I am retrieving and sending "Resources" (and deleting them, and yes there are arcane differences between PUT and POST) and have some standard status responses (400). These Resources have some structure, HTTP knows nothing about.

When I am using WS over HTTP, I am sending documents, that have a structure, HTTP Knows nothing about. And I am super imposing some semantics, HTTP knows nothing about, but with

PUT foobar/customerCollection/{partnerId}

I am still imposing the same semantics (I probably have to update some mainframe system as well). So what's the big difference.

Claiming I shouldn't abuse HTTP sounds like the Gospel according to REST.

But I think that "abusing" HTTP is only a side issue in the REST vs. WS debate.

PS: why is there all the whitespace at the end of my postings?

Silver Bullet by Daniel Joseph

Yes. Finally we have the silver bullet. In other words, if you find anything that can not be implemented elegantly in REST, you have a problem in your design/architecture.

Re: Religious Issue? by Stefan Tilkov

I don't think there's anything religious about the "abuse" argument. HTTP was designed as an application protocol with particular strengths (and of course, weaknesses). Using only 5% of it - i.e., just POST, a small numer of URIs to identify "endpoints", and only two response codes - dumbs it down drastically and degrades its role to that of the underlying transport (TCP).

Regarding the RDB analogy: just like you can't meaningfully use SQL in the example above (and thus defeat the RDB's purpose), you can't use hypermedia or caching when using WS-* and HTTP. Seems very similar to me.

Does it merit the word "abuse"? Who knows. It's just words.

Great article by Bill Burke

Stefan, these two articles are a must read for any REST noob. Thank you for articulating so well the points I fumble to try to explain to others when evangelizing REST.

On transactions, I have similar fears that distributed transactions and loose coupling don't mix. It was enough hard to get this stuff to work in a CORBA environment because of different vendor spec interpretations and lack of interoperability certifications. I can imagine it is even worse in the WS-* specs which are generally moving targets. I wrote down some thoughts on redefining the problem and solution awhile back. I always thought that these large b2b transactions needed to be modeled rather than abstracted away by specifications like WS-BA.

I also loved this quote from your article: "Trying to dumb widely different options down to their least common denominator serves no-one. An analogy would be to create a common abstraction that hides a relational database and a file system under a common API. Of course this is doable, but as soon as you address aspects such as querying, the abstraction turns into a problem."

I'm hoping this is a stab at the JDO crowd :)



Bill Burke
JBoss, a division of Red Hat

+1 to REST by Renat Zubairov

Very nice article indeed. Especially I liked the Atom/RSS ideas for pub/sub. Really interesting. Will definitely try out.

Re: Religious Issue? by Daniel Yokomizo

but this kind of CRUD methods, you could quite simply map to their RESTful equivalents.
But what about
 (d) scoreCustomerMortgageRisk(customerId) 
// i.e. the customer has send in a mortgage application,
// that should now be "scored" to decide if we can offer
// him a credit contract

(e) promoteToCustomer(personId)
// a person that is in our system, will now become a
// customer (an account will be opend, etc.)

(f) calculateNetInterestRate(credit)

I'm a REST proponent, but I also understand that it is <em>a</em> architectural style so your app may have different constraints and that's fine. Now looking at your examples I would ask the following questions: (d) How do we get feedback about this process? Is it synchronous or asynchronous? Do we talk about the scoring process itself? As an answer to those questions I would model it as a subordinate resource under the mortgage application so we can just PUT /mortage-application/{id}/score. Likewise we should be able to see if the score is done by issuing a GET. (e) What happens if a promotion fails? Do we keep track of who was promoted? As with (d) in most organizations people talk about promotions as objects with its own attributes (e.g. date of promotion, reason, who made the sale) so I would see no problem in POST /people/{id}/promotions resulting in a 303 with Location: /customers/{id} (it's important to remember that a resource may be acessible via multiple URIs so it's entirely possible to an action in an URI cause effects in other URIs). (f) seems to be a simple calculation process, I can't immediatly identify a resource associated with it, other than a calculator (which may be a proper resource in some cases but in this one it just smells like a RPC in disguise), I would have no problems with having it be a regular SOAP based WS, but I would try to understand the domain better to see if there's a natural resource attached to the calculation.

Re: Religious Issue? by Sean Sullivan

But what about

 (d) scoreCustomerMortgageRisk(customerId) 
// i.e. the customer has send in a mortgage application,
// that should now be "scored" to decide if we can offer
// him a credit contract

(e) promoteToCustomer(personId)
// a person that is in our system, will now become a
// customer (an account will be opend, etc.)

(f) calculateNetInterestRate(credit)

There is a similar discussion in IBM's article "Resource-oriented vs. activity-oriented Web services"

Towards Greater Clarity by Dan Creswell

Hi Stefan,

I am somewhat torn over this article. Some of it I like a lot, some of it feels a little wide of the mark. What follows are notes/questions which I hope we can use to lever out some further clarification....

On (2) - the schema information you mention describes the format of the data exchanges but it's missing an expression of the endpoints at which the interaction takes place. Of course this stuff lives in the HTML you mention later however this is not a "standard".

WSDL by contrast contains all this information in one place and in turn lends itself to stub/skeleton generation and that's what many developers find appealing.

Which option one prefers is determined by the desire for greater automation or a desire to engage in some thought, dig through some documentation etc.

On (4) - I don't think you've actually addressed the doubt here. REST itself is an abstraction and it's often put over the top of data and operations implemented in the usual three-tier style. i.e. The usual systems architecture hidden behind a Web "facade".

"Depending on a widely accepted, officially standardized protocol such as HTTP is not really a problem" - widely accepted is not the same as widely used and there are systems out there that need integrating that don't do http. These systems are often hidden behind firewalls away from the Web and are important to "enterprise" programmers whilst being almost invisible to many "web" programmers.

I think the real issue that needs surfacing here is can one do REST without http?

On (5) - An observation:

If one is designing with WS-* be it for Web Services or othewise, we're following patterns (rightly or wrongly) that have been evolved via CORBA, EJB and so on in our designs. i.e. There's a lot of history that people are used to and immersed in.

REST in contrast does not have such a widely communicated and agreed set of patterns yet. Sure there are a number of people programming on the Web but do they think Web or do they think Enterprise? I suspect that those thinking Enterprise are in the majority.

I'm not sure the leap on into SOA helps you here. One doesn't need to be doing SOA at all to be building a Web Service with WS-*. In fact SOA for most people is merely technology driven architecture and thus they are simply following their normal implementation patterns. They aren't thinking at architecture level as one might (but doesn't have to) do with REST.

And that's the nub of the issue - if one thinks in terms of architecture one agrees on patterns etc, if one get's lost in the technology it's all about religious biases and there will be little agreement. Think you're better off steering clear of that....

At the end of the day I view SOA (and REST as well) as one means of doing what good architecture is all about. Splitting up your system into small manageable pieces and exposing them in an appropriate fashion via http or CORBA or Messaging or RMI or whatever. However I suspect that most don't share this view.

On (6) - REST has little to say explicitly about transactions whilst the WS-* specs and SOA bigots do. That's a problem if one views the world transactionally or needs a transaction.

ACID may or may not be desirable within a system, sometimes one needs it, sometimes one doesn't. By preference we should strive to avoid it because it's a scalability/availability inhibitor. However in some cases it is necessary and the fact that REST says little will cause people to veer toward WS-*.

We must not forget that ACID amongst other things determines how an observer sees updates manifest. If we can stand them to be eventually consistent, distributed transactions aren't required. Sure one can attempt to bundle all information affected by a distributed transaction together (and remove the need for a transaction) but that can lead to large unwieldy chunks of information which is a bad design smell in itself.

On (7) - WS-Reliable Messaging is yet another example of centralized solutions to reliability which are generally believed to solve all reliability problems. They don't of course but the perception they do manifests as a requirement on REST.

The only way to achieve total reliability is for every single point in a system to maintain sufficient persistent state that it can remember what is was doing and recover as necessary (that would include the human being driving the application, if any). Many people equate message brokers with being the way to do reliable. They've failed to realize that a message is only durable/reliable once it's replicated on disk or in the memory of a number of machines in a cluster. i.e. If the client has no persistent storage and fails half way through transmitting a message to a broker for "reliable messaging" the message is lost forever unless there's something that remembers to resubmit.

A further issue is that whilst these reliable brokers will eventually deliver a message they don't necessarily provide any consideration of timeliness of delivery which can be troublesome under various circumstances.

On (8) - The whole pub/sub, pull/push thing has been done before:

Polling is an efficient way to scale for data that is changing slowly and viewed by a large number of clients. Polling doesn't always work so well for highly volatile data. I would venture to suggest that one would need to be looking at other messaging solutions for this be they traditional brokers or AMQP/XMPP implementations.

On (9) - You may have meant this when discussing the option for a client to pass a URI - Many people when dealing in asynchronous processing also want an event delivered to the client to identify when it's completed as opposed to the polling model you apparently suggest.

Protocol independence by Marc de Graauw

Another counter-argument to the 'protocol independence' argument: it is mostly mentioned when support for legacy is required (message goes over HTTP, then JMS, then MSMQ etc...): but legacy typically does not support the WS-* stack either. So you'll either have to build a gateway or update the entire legacy chain anyway.

Re: Towards Greater Clarity by Stefan Tilkov

Hi Dan, thanks for the detailed remarks. Let me try to address some of them:

With regards to (2), schema being the most relevant part of WSDL, I know many developers love having the code that handles XML to be generated for them. While I'm not among them, I understand the desire -- and tools to do this are available when working with REST, too.

You are right that if you want to have code generated for more than the data part, WSDL has the metadata that allows you to do so. In practice, I consider this too be much less of a concern.

Regarding (4), protocol independence, my main intent was to say that if I have the choice to standardize a) on HTTP or b) on Web services, I consider option a) to be the one that's far more widespread and supported than b). Therefore, I don't consider hiding HTTP below a layer of abstraction a goal worth pursuing. There may be a lot of situations, of course, where HTTP is bad choice, and something else might make more sense. That's fine, too; just use it, but don't try to turn HTTP and, say, AMQP into the same thing by adding a layer on top (because they aren't the same thing at all).

I can agree with most of what you observe regarding (5). I still claim that two people tasked with solving a problem using RESTful HTTP will arrive at a solution far more similar than two people doing so with WS-*, CORBA, EJB or DCOM.

I agree on (6).

Similar, no disagreement on (7).

On (8), I think we agree that polling doesn't always work, and other solutions may be better for a significant number of use cases. I can't comment on the XMPP/AMQP combination for lack of experience, but it seems one worth considering.

Regarding (9): Yes.


Re: Religious Issue? by Stefan Tilkov

Quoting from James Snell's article:

To offer a contrast, compare this with a recent proof-of-concept project IBM implemented to illustrate the use of Web services to automate hospital patient records access, prescription writing, operation scheduling, and so forth. Without going into any details (which are covered by a non-disclosure agreement with the client), the primary focus of the collection of service interfaces created for the system focused strictly on activities that users could perform in the system. For example, scheduling a procedure or a test for a patient and requesting asynchronous notification of such events as availability of test results. While patient records (resources) are an important aspect of the system, they generally serve a supporting role in the overall application and are not the central focus of the system. Rather, the hospital prototype is an activity-oriented service, which is accurately reflected by it's SOAP-style Web service architecture.

I'm pretty sure James, who is the driving force between the AtomPub implementation Abdera, would view things differently now. This particular use case, IMO, is a great example of something that could be mapped to a RESTful without much difficulty, yielding a lot of benefits -- such as being able to link to individual results, producing feeds for changes, linking to images ...

Re: Towards Greater Clarity by Bill Burke

On (9) - You may have meant this when discussing the option for a client to pass a URI - Many people when dealing in asynchronous processing also want an event delivered to the client to identify when it's completed as opposed to the polling model you apparently suggest.

Imagine how much simpler and portable this would be if modeled in a RESTful way? If the protocol was HTTP, the message producer could just append a custom "reply-to" header with the URI of the reply-to queue. The consumer of the message sees the header and just does a POST to it.

I do agree that some REST over HTTP standards should be put in place for doing things like transactions and messaging. I imagine they would be a lot simpler and easier to implement :)

I think another thing to consider is why is REST gaining in popularity? Once you start researching this you start to see why a lot of distributed computing veterans are finding the model so appealing over WS-*.

My answers to 5 of these doubts by Ganesh Prasad

1. REST may be usable for CRUD, but not for “real” business logic

If CRUD appears too fine-grained, remember that the definition of the "resource" can be arbitrarily coarse-grained. Creating a new Bill of Lading in a shipping application is just a PUT or POST operation as the case may be, but the accompanying XML document has sufficient richness and complexity for the operation not to be considered fine-grained.

2. There is no formal contract/no description language

I've explained why REST does not need a description language in my blog post REST Eye for the Relational Guy. In short, when the basic interaction patterns are made uniform, they become "assumed knowledge" and don't have to be explicitly described. Only application data needs to be described.

3. Who would actually want to expose so much of their application’s implementation internals?

If you're exposing domain objects directly through a RESTful interface with no service-oriented interface design, that could indeed be a problem. But REST done right provides the appropriate abstraction to decouple what the application client sees from the actual domain model being implemented. I've blogged about this property of REST as well.

7. REST is unreliable

While people often demand reliability, they will usually be satisfied with idempotence. In fact, in any distributed computing environment, end-to-end reliability is a chimera anyway, as illustrated by The Two-Army Problem. REST is perfectly capable of supporting idempotence through design patterns such as the proposed standard "POST-Once-Exactly". It's trivial to implement this design pattern within your application's logic, even if the proposed HTTP-related standard doesn't materialise in your project's timeframes. Investing in six-figure reliable queueing infrastructure still doesn't solve the problem of end-to-end (i.e., application-to-application) reliability.

10. Lack of tools

If you have the tools to build conventional web applications, you already have most of the tools required to build RESTful applications. The only additional tools you may need relate to XML definition and processing. All of these are stock-standard and readily available.


Ganesh Prasad

Example REST interface in an enterprise product by J Hwang

Splunk's latest version uses REST with Atom syndication to power its backend. It's a marked improvement over SOAP, our previous interface, and definitely makes interacting with the product far easier. Our integration partners are definitely much happier with it as well. I have a blog post that elaborates on our design decisions:

Re: Religious Issue? by Roshan Shrestha

Off tpoic, but regarding a generic database model, there is the Entity Attribute Value (EAV) model that has seen some usage and seems appropriate for some cases

Re: Religious Issue? by Victor Volle

I tried to eleborate on my comment a little bit more thoroughly:

Re: Security? by Rolf Rander Næss

If you want to add security on the message-level, using existing XML-standards, this is true, you must implement it specifically for your REST-app. However, the point of REST is to leverage HTTP, which already has mechanisms for encryption, password authentication and one- or two-way pki-authentication. All available through configuration in your web-server, no need for programming.

Good points by Arun Batchu

All good points Stefan.
> Lack of tools
Tools everywhere! The browser becomes your IDE; Or your <favorite programming language> IDE; or XML IDE or XQuery tool
> Transactions
The RestFul book has a very interesting take on how to do transactions in a RESTful way. I like it (not used it though).
BASE vs. ACID properties is an interesting way to reconcile transactions. You touch upon the scaling issues of 2PC protocols. Just can't do it.


Re: Good points by Arun Batchu

Apparently, I cannot put angle brackets - my fault.
I meant to convey that your favorite programming language IDE and any tool that can handle a URI/URL (hence the browser) becomes a tool to test and write your RESTful services.

Re: Religious Issue? by shruti chinni

Hi Daniel Yokomizo,

I have been searching for some explanation for complex business logic handling in REST. Your post does clarify how we should modify our viewpoint with respect to the complex business logic. But now my question is that is the utility that we gain out of this "complex" viewpoint of the application process worth the effort, when it can be replaced by service-oriented approach. One of the arguments was that SOA requires the knowledge of the web service for it being used. But doesnt that apply for REST too.

We need to know the process, in the very least, in order to call the "correct" URI? How loosely coupled is this as compared to the SOA version?

Some problematic cases by Mark Kron


Relating to point 5, I'd like to share with you some problematic cases. I like the REST idea that for actions (verbs) you use standard set of protocol methods and URLs identify things (nouns). These are example cases which I was not able to easily fit into this picture:

1. Application has two lists of similar things: A and B (say identified as /app/A/<some id> and /app/B/<some id>). In the interface I want to expose an action that means "change given A to became a B" (or "move given thing from list of A to list of B").

2. Application has list of things of type A. In the interface I want to expose two separate views for A, not differing by the returned media (html, xml, pdf etc.) but by the data set, say: basic view and detailed view.

3. Application has list of things of type A. In the interface I want to expose a custom operation on a selected item, which is not simple update with data that comes from a client, but from the server, and client only triggers the operation. Say: "refresh A" or "reset A".

What are your proposals of REST interface for these?

Kind regards

Security by Shivendra Dubey

I have seen comments for security with REST. But i am not sure how are we going to protect data which is passed in URL (in case of using HTTP GET). The URL is going to go over the internet and can be hacked anytime.

+1 for self documenting resources by Juergen Brendel

Hi Stefan,

I like your comment about the self documenting resources. That's exactly right: You still need a human readable documentation. If your resources are discoverable (follow links) you have a very nice system in place, which allows people and even search engines to find the resources you can offer.

We did that for RESTx, where each component (pieces of code that act as the basis for resources) and each resource (particular configurations for that component) are discoverable and show a human readable description.

If you are interested, you can see how you can take a tour of the RESTx server, just with a web browser.

Re: Religious Issue? by Hasko Heinecke

Hi Victor, long time no see :)

I agree with your sentiment, there is not just one true way.

However, to address the three very good examples you brought up, consider this:


Actually, here the client making implementation assumptions about the backend. Indeed, the risk score is a property of the mortgage application. The client wants to know the risk score? Go ask for it.

GET .../mortgageApplication/{id}/riskScore

Or perhaps the risk score is really just a property in the mortgage application entity itself. (I'm talking about the application like the form you fill out, not the IT kind off application consisting of lines of code, just to clarify.)

In your SOAPy example, you are telling the backend to actually calculate it. Maybe someone already calculated it. Maybe calculation will take overnight until the risk cube is recalculated. Don't tell the backend what it should do, tell it what you want to *know*.

In that sense, the RESTful alternative has less coupling: It doesn't make assumptions about when a risk score needs to be calculated. It delegates this decision to the backend, as it should.

Your third example is just the same. Again, ask what you want to know (the net interest rate) and don't tell the backend what to do (calculate the rate). Let the backend do its job. That's how coupling is reduced.

Your middle example is also interesting. There are different RESTful strategies here. One could argue that you should just GET the client, adding the prospect's uri (or an id) as a parameter. Then the server should see that the client doesn't exist and promotes it if possible, returning the ready made client.

However, I think in this case the failure modes are too complex. Promoting a prospect to customer could return in various states. It could fail because preconditions aren't met. It could semi-complete, lingering in an intermediate state because, say, there's a second signature missing. It could succeed but you're not allowed to access the customer because they're assigned to somebody else. Whatever, I believe it's not a good idea to whop that all together in a single GET request that is intended to retrieve existing customers.

So I'd argue you need to create a request entitiy for promoting the prospect to customer.

CREATE .../prospectPromotionRequest/{prospectId}

This request can then be GET-ed to check its completion status and any complex failure modes. It might not even result in a new customer at all but rather a workflow task entity or whatever.

The idea to turn an operation into a request for performing the operation may seem very German (or Byzantine) but in fact that's how a lot of batch processing in financial institutions already work. It lends itself also quite nicely to the documentation requirements of today's equally byzantine regulatory environments. So while this may not reduce coupling as compared to the original soapy operation, it has other beneficial features.

So yeah, it's not always easy to come up with a good RESTful design and I'm not saying mine is the One True Way. But once you get in the RESTful headspace, there's sometimes surprisingly good solutions that go beyond just WS vs. REST.

Re: Religious Issue? by Hasko Heinecke

... and yes, I know that it's POST and not CREATE. ;)

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

38 Discuss