Article: RESTful Services with Erlang and Yaws
- Share
-
- |
Read later
Reading List
In a new InfoQ article, Steve Vinoski, known as one of the world's leading authorities on middleware, takes a look at how to build RESTful web services using the Erlang programming language and the Yaws web server.
Erlang has seen a renewed interest because it is, together with the accompanying Erlang/OTP framework, built specifically to exploit parallel computing resources. In the article, Steve shows how Erlang's features are a match for implementing RESTful services, specifically discussing how to map an application's URI space to Erlang program code.
Check out the full article here.
4
Discuss
Erlang has seen a renewed interest because it is, together with the accompanying Erlang/OTP framework, built specifically to exploit parallel computing resources. In the article, Steve shows how Erlang's features are a match for implementing RESTful services, specifically discussing how to map an application's URI space to Erlang program code.
Check out the full article here.
Rate this Article
- Editor Review
- Chief Editor Action
Submit
Submit
Related Sponsor
Are microservices really just “SOA done right”?
Download this exclusive O’Reilly Report to find out.
Hello stranger!
You need to Register an InfoQ account or Login 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
Community comments
Repeatability
by
Erik Onnen
Posted
Re: Repeatability
by
Erik Onnen
Posted
Apples And Oranges
by
Paul Tiseo
Posted
Missing hypermedia
by
Guilherme Silveira
Posted
Repeatability
by
Erik Onnen
Hey Steve,
Thanks for the article. In my own testing, I've seen Yaws fall over and die under a load of ~20 concurrent requests. This really begs the question, what can we do to repeat Joe's tests? The documentation and code of "the test" are sparse, and they aren't public so it's impossible for anyone to reproduce the same numbers. Given that, I can only assume the Yaws numbers don't take into account dynamic content, something that is important to most developers. Any thoughts there?
-erik
Thanks for the article. In my own testing, I've seen Yaws fall over and die under a load of ~20 concurrent requests. This really begs the question, what can we do to repeat Joe's tests? The documentation and code of "the test" are sparse, and they aren't public so it's impossible for anyone to reproduce the same numbers. Given that, I can only assume the Yaws numbers don't take into account dynamic content, something that is important to most developers. Any thoughts there?
-erik
Re: Repeatability
by
Erik Onnen
Also, I'm curious about your mention of Erlyweb. How many people are maintaining Erlyweb? For those of us who are interested in the comminity there, how many people actively contribute to Erlyweb?
Apples And Oranges
by
Paul Tiseo
While I am learning Erlang because it seems to be an emergent language I should have in my toolset as a developer, I fear the "famous graph" at the start of the article, used as a teaser, is perhaps misleading.
First, are Apache and Yaws comparable? How much of Apache's functionality set is found in Yaws? Second, what was the test configuration for that graph? Also, no mention is made of the follow-up benchmarking
I mean, if a writer starts an article with: "Whether or not you should use X, here's how you'd use X...", shouldn't the "whether or not" part be well-established rather than open to debate?
First, are Apache and Yaws comparable? How much of Apache's functionality set is found in Yaws? Second, what was the test configuration for that graph? Also, no mention is made of the follow-up benchmarking
I mean, if a writer starts an article with: "Whether or not you should use X, here's how you'd use X...", shouldn't the "whether or not" part be well-established rather than open to debate?
Missing hypermedia
by
Guilherme Silveira
Hi Steve,
Although the example almost reaches REST in a really simple way, it is just missing the HATEOAS point when leaving the hypermedia aspect behind. It is much easier to develop thatn SOAP based solutions, but without hypermedia support, both clients and servers are coupled in a way that REST systems should not.
Regards
Although the example almost reaches REST in a really simple way, it is just missing the HATEOAS point when leaving the hypermedia aspect behind. It is much easier to develop thatn SOAP based solutions, but without hypermedia support, both clients and servers are coupled in a way that REST systems should not.
Regards
