Comment by BringTheTanks | Hacker News Reader

Comment by BringTheTanks | Hacker News Reader

Parent Full thread

Let's quote from section 5.2.2:

"All REST interactions are stateless. That is, each request contains all of the information necessary for a connector to understand the request, independent of any requests that may have preceded it. This restriction accomplishes four functions: 1) it removes any need for the connectors to retain application state between requests, thus reducing consumption of physical resources and improving scalability; 2) it allows interactions to be processed in parallel without requiring that the processing mechanism understand the interaction semantics; 3) it allows an intermediary to view and understand a request in isolation, which may be necessary when services are dynamically rearranged; and, 4) it forces all of the information that might factor into the reusability of a cached response to be present in each request."

When the paper was written, the per-user requests were supposed to be an exception, a minority case.

HTTPS will effectively make everything opaque and "per-user", and hence everything I quoted above which refers to intermediaries will no longer matter.

Restrictions in 5.1.3 ("Stateless"), 5.1.4 ("Cache"), 5.1.5 ("Uniform interface") and 5.1.6 ("Layered") would no longer apply either. All intermediaries will see is encrypted data, so shared data and functionality as explained can no longer be moved to an intermediary.

BTW, parent, way to selectively refer to a phrase in Fielding's paper while missing the point of 99% of the rest of it.

Sorry for the short response, I was on mobile.

The part of 5.2.2 I was referring to is this:

If some form of user authentication is part of the request, or if the response indicates that it should not be shared, then the response is only cacheable by a non-shared cache.

This clearly indicates that returning different versions of the same resource on a per-user basis is valid REST architecture (and I was responding to the comment that Equal GET requests will often have different results based on the user doing them is very non-REST.).

While it is only one phrase, it is the only phrase that deals with user authentication and matches the discussion very well. As such I think your comment about missing 99% of his thesis is incorrect - indeed, I think choosing the correct and relevant part is precisely what "getting the point" is about.

I agree with your points about HTTPS, but that is orthogonal to the user authentication discussion in the sense that transport-layer is separate to the API design.

However, I appreciate that your points about how the transport layer affects the assumptions around API design are correct, and that going to a HTTPS-only transport mechanism may have performance impacts in many cases (especially high-volume ones).

I know which phrase you're referring to, but if you read it in context, it's apparent this is an exception case, because the very same section talks about cacheable, stateless requests and responses.

All of REST's constraints are about encouraging cacheability and "visibility" to intermediaries. Intermediaries should in most cases be able to see which resource is being requested/returned, read the method, read the content-type and other headers.

All of this is not available during an HTTPS session. So "HTTP + a bit of HTTPs" is REST + a dose of realism.

But "HTTPs-only" is something else entirely.

I think we are dramatic agreement?

HTTPS = breaking caching.

User Authentication = returning different results for per-resource queries, which is RESTful.

I'm afraid we're not in a dramatic agreement. You point to an exception which REST allows to claim the exception is RESTful.

The exception is there for practical reasons and it doesn't satisfy REST's constraints nor benefits from REST's properties.

Either way, my point's been exhausted, so, I'll shut up now ;)

Reply on news.ycombinator.com