We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion
SOA
user-pic

Are REST-Based Services Capable of Supporting Enterprise-Grade Functions?

Vote 0 Votes
Joe McKendrick: Are REST-based services capable of supporting enterprise-grade functions?

5 Replies

| Add a Reply
  • Very much so. In the simplest example many applications simply need access to small or even large chunks of data. What better way to get this that to issue a REST GET request for the data and have it delivered as a response ? It can also provide benefits more complex scenarios where updates to resources are required. FOr example, many organizations use 'triggers' by writing data to a file. Why not do this with a REST POST/PUT request as a very simply way to trigger some process on a remote machine to that which the current process is running on.

  • Assuming the question relates to pure REST (i.e. as defined in Roy Fielding's thesis) and not to the pseudo-REST practices that have been proliferating lately, I don't see any reason why it could not in principle support enterprise-grade functions. At the same time, I see many obstacles in achieving that goal in today's enterprises. Here are some reasons:

    - Cultural mismatch among enterprise business stakeholders: REST is based on run-time service contract discovery, while traditional enterprise service architectures are focused on design-time command-and-control and rely on well-known design time contracts (service registry descriptions, BPM models, etc.).
    - Cultural mismatch among IT practitioners: most "REST" developers have never even read Roy's thesis and have no idea of the importance of things like HATEOAS (Hypermedia as the Engine of Application State). Many developers have bought into the hype of REST being easier to program than Web services, while REST clients can actually be more complex because of the run-time service discovery aspects.
    - Lack of well-developed tools and development frameworks (just compare the number of REST frameworks available today with the corresponding number of Web Services-based frameworks).
    - Lack of well established practices and patterns in areas crucial to the enterprise (e.g. end-to-end security, reliable messaging).

  • To be honest, I think this question is a bit silly. Of course REST can support "enterprise-class" services. While REST doesn't have to be done over HTTP, that's certainly the most frequently used option, and you can't tell me that enterprises aren't using HTTP everywhere today. There are certainly decisions that have to made regarding passing identity to services, but there's definitely options available. In short, there's nothing technology related that is a problem. Just as with Web Services, the barriers are probably more cultural than technology. An organization needs to figure out how to do resource management. If everyone just arbitrarily creates their own resource identifiers, you can get yourself in trouble, just like if people went off and created arbitrary web services.

  • The question itself is way too vague (define enterprise function) So the answer is 'it depends'. A few use cases exist where REST might be less ideal. For example, with WS-Security you can specify partial message encryption, while with REST for the most part you rely on whatever security comes with the normal HTTP protocol or HTTPS. Distributed transactions are another area where WS-* offers more support.

    On the other hand, most 'enterprise functions' do not require partial message encryption or distributed transactions. Instead, they are about relatively simple data access, in which REST tends to be perfectly suitable. In fact, publishing information in an easy to digest manner to users, customers or partners is one of the key functions in enterprise IT. A RESTful resource - handled via a simple URL and consumable by client applications and web browsers alike - is the ideal vehicle for that.

    Many of the concerns or question marks about REST stem from the erroneous assumption that it is just "RPC via URL". That's not the case. In a RESTful system, you tend to think about 'data', while in WS-* you think about 'function'. It's not a 1:1 mapping between the two. Once people manage to adjust their thinking to focus on the data resource (which is not necessarily easy to do) many of the concerns about REST begin to evaporate.

  • This is a little like asking “Can cars support a courier company?â€? Well, maybe. But it’s kind of a nonsensical question that suggests that the courier has to make a choice between cars or trucks. If they need to deliver an elephant every once in a while, a truck sure would be handy. If they only ever deliver documents, then cars make more sense. For most couriers, the logical answer is a mixed fleet—this way, they can deploy the transport that best solves each business problem.

    I just hope we don’t have to add bicycles into the mix.

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT