• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

REST web service - volume?

 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello, I am relatively new to web services, and I am trying to figure out the robustness of REST web services.
Can the experts on the forum please point me to any resources that talk about how many web service calls a REST implementation can handle?

I can try and rephrase this if my question is not clear enough. TIA
 
Andy Cohn
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just wanted to add that there is a load balancer but for the purpose of the discussion, we can assume that it is just one server handling the requests.

I am basically looking to quantify it - 5 requests per second, or 100 per minute or something like that... some number to kickstart other conversations. I know it will not be accurate and that there are several dependencies...
 
Ranch Hand
Posts: 51
1
Eclipse IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Your question is pretty generic but I will try to give an answer and if it is too verbose or off the mark I will probably need more specific questions.

Firstly, the volume/capacity of any web service (as you've noted) is not so much a function of the type of web service it is (i.e. SOAP, REST, RPC, POX, etc) as much as the topology (architecture) on which the service is built (e.g. multi node, multi core, load balancer, highly-available, etc, etc.). A REST web service will not very much more volume than any other type of service if it is running on low powered physical or virtual hardware, just like any other type of web-based architecture.

That being said, RESTFul web services are gaining popularity over the more traditional style of web services (SOAP has been the most popular protocol in last 10-15 years), and one of the reasons for that is that they are much more lightweight than SOAP web services with a lot less redundancy. As such, they are quite well suited to high volume, low latency "micro service" API (a separate topic in its own right). The trade off is that they don't provide the rich metadata and "transport agnostic" messaging paradigm that is embedded in SOAP. Some will argue that in a http cloud-only world, that doesn't matter. I personally think it does, and REST web services are in many ways to SOAP what NoSQL database engines are to RDBMS - they are an alternative, not a replacement.  

A side note, but it is important (to me, at least) to note here that REST (or "representational state transfer") is actually not a unique acronym for "web services", but it is in fact the term that describes the architectural style of the web; all interaction that uses TCP/IP (HTTP) is, technically, implementing the REST pattern (in other words, every website in existence, including this one, implements REST). However, the term has been hijacked and somewhat narrowed to describe a certain type of web service that is tightly coupled with HTTP , and typically uses JSON format for request/response message payloads. As such, some caution is advised when you hear "REST vs SOAP" - technically this is not comparing apples with apples and can be misleading.

RE your question on exact numbers, I cant give you that as it depends on far too many factors: size of payload, processing speed, business logic, etc. But it is certainly true to say that you can gain performance improvements over using SOAP/XML based messaging, by implementing a RESTFul style with JSON.
 
Andy Cohn
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you for your response. Let me try to explain where I am coming from.

My application interfaces with a different application over a set of RESTful webservices. This is a predetermined constraint. So as we develop our client code, there was a suggestion from the team that we need to insulate our business logic from the REST client by using a JMS layer in between. The benefits that it was supposed to offer was buffering/queuing if there was high volume. I didn't see a need for this JMS component, and am trying to understand what volum could possibly need this sort of additional messaging.
 
Rancher
Posts: 4801
50
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The limit is going to be pretty much down to what the service itself is doing.

You can make thousands and thousands of requests against a server running on a very basic machine if all those requests do is respond with "foo" and do no processing.

Added to what Theo says, it's essentially a function of the target platform and the actual service provided.
 
Theo van Kraay
Ranch Hand
Posts: 51
1
Eclipse IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
From what you write, the proposal to use JMS as a mediator would make sense if:

1. the REST web service container itself is locked down and cannot be horizontally scaled any further.

AND

2. The REST web service layer isn't adequately scaled to cope with volumes that your interfacing application will handle.

Of course, the far better thing to do in most circumstances (unless  the web service container is particularly intolerant to downtime from a business/non-functional perspective) is to just scale out the web service layer without introducing JMS. However, taking point 1 as a given, it sounds like someone has then made the judgement call on point 2.

Again, there isn't anything intrinsically specially about REST (anymore than there is about any other website - see earlier comment) such that this screams "unnecessary". If the REST container's topology really can't cope with the volumes of the consuming, you of course need to either scale out or offset the load. By the same token, there isn't anything especially "fragile" about REST either. Its just a client/server container like any other but with the specific function of providing technology stack agnostic API container available through the RESTful service.

How have the person/team demonstrated/proven that the REST container isn't adequately scaled, such that the JMS mediator is necessary? That would be my question.
 
Andy Cohn
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Dave and Theo - we had more discussions, and we are proceeding with the design as is. The JMS layer, while offering the standard benefits of a messaging layer, was also going to interact with other non-RESTful components outside our domain. Thanks very much for your help!
 
reply
    Bookmark Topic Watch Topic
  • New Topic