[erlang-questions] YAWS RESTful examples

[Steve Vinoski]

On Sun, Feb 6, 2011 at 10:32 AM, Alain O'Dea <alain.odea@REDACTED> wrote:
> Hi David:
>
> I totally agree with Lukas.  I could bot make heads or tails of REST on YAWS.  It seemed like a square peg in a round hole.

No offense, but I don't think this statement makes much sense because
it implies that writing RESTful applications with Yaws is impossible,
which most definitely is not the case:

http://www.infoq.com/articles/vinoski-erlang-rest

Yaws is an extensible web server with which you can write server-side
web applications. It provides complete information about every HTTP
request to your application, allowing your app to react to each
request appropriately, and allows your app to completely control
response headers and return any form of content it wishes to. Thus,
writing a RESTful app on Yaws is entirely a matter of structuring and
writing the app correctly. The means by which you access request
details and provide responses with Yaws are fairly well documented at
http://yaws.hyber.org/ and if you can't figure something out, send a
message to the yaws mailing list:

https://lists.sourceforge.net/lists/listinfo/erlyaws-list

Last year Justin Sheehy and I wrote about Webmachine here (PDF):

http://steve.vinoski.net/pdf/IC-Developing_RESTful_Web_Services_with_Webmachine.pdf

Note that Webmachine is itself a framework that sits on Mochiweb. I'm
sure it could run on Yaws equally well.

The nice thing that Webmachine does for you is encode the rules of the
HTTP application protocol, thereby making it hard for your app to get
those wrong, but that by itself is still not enough to guarantee
RESTfulness. Only the application itself, regardless of underlying
framework or web server, can determine RESTfulness.

For example, one of the most important constraints of the REST
architectural style is "hypermedia as the engine of application
state," which means for each request, the server uses hypermedia to
direct each client application (user agent) to possible next steps
given what it just requested. Many apps claiming to be RESTful fail
miserably on this critical constraint, and thus are not actually
RESTful, because they don't use a standard media type that supports
links (or use Link headers) -- they instead use custom media types
based on JSON or XML that require the client to be specifically
coupled to the server so it can interpret the custom media type. In my
InfoQ article linked above from 2008 I failed to give this critical
constraint the focus it requires.

--steve