Hacker News Reader

Comment by mgummelt | Hacker News Reader

Can you briefly describe what you mean by "In-Process REST" and what the benefits are? I tried to read your slides but couldn't understand them. Are these new in-process interfaces asynchronous? Or are they synchronous interfaces that adhere to REST principles?

View on HN

I talk about this in the Storage Combinators paper[1]

In-Process REST essentially means applying the applicable mechanisms of REST in-process:

1) URIs

2) a few well-defined verbs

Benefits:

1) Common, concise and familiar API for talking about storage. (Check how much API surface there is for talking about storage variations in typical OO libraries. In Cocoa, for example, it's atrocious).

2) Paths. For some of the benefits of paths in general purpose programming, see The Programming Language Aspects of ThingLab [2]

3) Avoidance of the architectural mismatch between storage-oriented problem domains (most of them), and procedurally-based implementation technologies.

4) Composability: this is the heart of the Storage Combinators paper, you can plug these things together to obtain the desired functionality.

5) Performance, at least compared to other ways of getting similar benefits, such as (over-)used of filesystems, FUSE, Microservices for architectural reasons etc.

...

[1] https://www.hpi.uni-potsdam.de/hirschfeld/publications/media...

[2] https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90...

I'll check out the paper, but at a glance, "a few well-defined verbs" seems to just mean you've introduced a set of standard storage interfaces, right? If so, calling this REST, to the extent which that word means anything at all, seems a bit of a stretch.

I just finished reading the paper and that’s what it looks like to me. It’s a CRUD interface w/ multiple implementations (proxy, cache, route, serialize, filesystem store, memory store), which they create pipelines out of using some syntactic sugar in the Objective-Smalltalk language. This syntactic sugar, discussed in their paper on ‘polymorphic identifiers’, allows you to use the same syntax for writing content to a file as you would writing to a key in a map or a field in an object. If you look at the pictures / tables in this paper, you get a general idea of what they are doing (e.g. replacing the filesystem store with a memory store while running tests). These dynamically dispatched processing pipelines are powerful, but can be hard to follow (which is true of dynamically dispatched processing pipelines in general). The power/obfuscation is multiplied by the convenient syntax of the language.

My opinion is that the actual innovation is the ‘polymorphic identifiers’ they introduced in their previous paper, which is definitely worth a read as my one line description of it can’t really do it justice. It’s kind of like being able to overload the assignment operator. Once you have that kind of feature, it’s sort of a no-brainer to say ‘Hey, all I/O (variables in memory, filesystems, etc) should use the same interface’.

For 10 years, people have been talking about REST as if it means something. I could never figure it out. If it means anything more than CRUD, it's lost on me.

I've had the same feeling and finally came to a few conclusion that Fielding's REST architectural constraints lead to client applications that are required to utilize undefined URIs for performance gains. The reason true RESTful APIs are scarce as compared to HTTP/JSON APIs is due to API developers recognizing this issue and choosing to deal with it by making URIs part of the API contract. The REST community has offered no additional guidance or answers other than to point out (correctly) that HTTP/JSON APIs aren't truly RESTful. That is OK.

Here is a much longer comment on reddit where I go through Fielding's thesis and a few other writings and show that following the constraints pretty naturally leads to the outcome above: https://www.reddit.com/r/programming/comments/2oyj65/api_des...

To me it means CRUD + stateless (no sessions) + naming convention. overall this is aimed at making api easier to reason about.

Well, and the URIs / Polymorphic Identifiers. The combination of these two is crucial. And yes, that's all it takes and yes, it is a bit odd. Took me a while to accept as well: the first system in the style was around 2004.

However, the In-Process REST paper[1] has a section listing the constraints of the REST architectural style, and we actually match those constraints very well, apart from the obvious bit of not being a distributed system.

The constraints (from Fielding's dissertation) are:

1. Client Server

That one's the obvious miss, as long as you define client and server as being separate computers.

2. Stateless

If you follow the model, then any state mutation is done via the "verbs", so yes. No more or less enforceable by the mechanism than in real REST.

3. Cacheable

Yes.

4. Layered System

See Storage Combinators. Yes.

5. Codee on demand (optional)

Doesn't make sense, so no. Optional, so no big deal.

6. Uniform Interface

This is the one with the URIs and verbs, so yes.

HATEOS was at least partially adhered to in the system we built, but again not enforceable by the model and also widely not adhered to in the wild.

[1] https://link.springer.com/chapter/10.1007%2F978-1-4614-9299-...

Reply on news.ycombinator.com