[julie1]

Nice you now understand why some people don't trust REST.

REST is based on a lot of optimism. Security is based on a lot of pessimism.

Building is a sane balance between both. Basically, you build slow to secure stuff.

Remember cathedrals were built for centuries by dedicated generations of small teams of highly skilled non compromising masons.

That's the way you build security. At the right speed.

openBSD is a going a tad too fast, and is a tad too big, but it is still quite secure and functional.

The problem is industry is wishing to make it go faster by throwing more unqualified man power creating a Babel tower effect.

Well, it does not seems to work.

[chris_wot]

Not sure why you think this shows why I shouldn't trust REST...

I can't see how REST is fundamentally insecure! Could you elaborate?

[julie1]

It is not REST that is unsecure by itself. It is people following ideas without critical thinking.

Maybe I only had _under brained_ CTO, but I always had problems in details. And even though I have been an architect/sysadmin, recently I went back to coding for others, because I prefer coding.

I saw a lot of mess in signaling the error code, or changing how to return them (is it an 5XX error or a { "status" : "bla", "error" : ... }) or even using the "PUT/GET/POST/DELETE" correctly.

Wrong handling of cache too... of HTTP headers, media type... authentication ...

Also trying to make distributed transactional systems without synchronized clocks on server (and with unsecure NTP source because editing the default ntpd.conf is sooooo hard). And denying the need of FSM for distributed REST servers because REST is supposed to be stateless. (lol)

Or the specs of rest limited to a nice HTML page with one example of the "right case" and no descriptions of the types and no informations on how errors are handled.

On the paper REST is great. In practice ... Oh boy. It is the PHP of messaging.

[chris_wot]

I think you probably need to read up on RFC 2616 again then, and in particular section 9, method definitions.

In terms of status codes, the RFC is very clear: "Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request" [2] so if you are returning a 200 OK when using REST and there server is indicating an error, then you are doing it wrong.

In terms of caching, OPTIONS is not cacheable; GET is cacheable if it conforms to section 13 [3], HEAD can be cacheable, POST is not cacheable at all, responses to [UT are not cacheable, likewise with DELETE.

As for REST being stateless - well, yes! HTTP is "a generic, stateless, protocol" - and indeed every request you send is an independent transaction unrelated to any previous request.

As for producing a distributed transaction system, sure if you have a distributed set of servers processing REST requests, without some sort of FSM it's going to be hard to implement... I just don't see this as a fundamental issue with REST.

As for "Or the specs of rest limited to a nice HTML page with one example of the "right case" and no descriptions of the types and no informations on how errors are handled" - aside from the HTTP RFC, REST is detailed in Roy Thomas Fielding's doctoral dissertation [4] and is a really great read, I recommend reading it if you haven't already as it details many of the things you raise as issues.

1. https://tools.ietf.org/html/rfc2616#section-9

2. https://tools.ietf.org/html/rfc2616#section-10.5

3. https://tools.ietf.org/html/rfc2616#section-13

4. https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...

[icebraining]

REST is based on a lot of optimism.

REST is based on the observation of the communications patterns developed for the web. Optimism? About what?

And by the way, OpenBSD includes a RESTful server in its core projects.

[chris_wot]

REST works well over HTTP as it handles hypertext, but it's interesting that Fielding wrote the following:

REST does not restrict communication to a particular protocol, but it does constrain the interface between components, and hence the scope of interaction and implementation assumptions that might otherwise be made between components. For example, the Web's primary transfer protocol is HTTP, but the architecture also includes seamless access to resources that originate on pre-existing network servers, including FTP, Gopher, and WAIS. Interaction with those services is restricted to the semantics of a REST connector. This constraint sacrifices some of the advantages of other architectures, such as the stateful interaction of a relevance feedback protocol like WAIS, in order to retain the advantages of a single, generic interface for connector semantics. In return, the generic interface makes it possible to access a multitude of services through a single proxy. If an application needs the additional capabilities of another architecture, it can implement and invoke those capabilities as a separate system running in parallel, similar to how the Web architecture interfaces with "telnet" and "mailto" resources. [1]

1. https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...