This is an interesting little paper. It’s riddled with funny typos and wanders often from the subject of API design but it’s still worth a look

REST as a state machine

So this is something that this paper talks about more than most. I think it’s in line with the RESTful concept of action URIs, and we can define the state machine more vigorously with our domain modeling tools

Comparison with GraphQL

• Obvious roundtrips and over/under-fetching points
• Native “sophisticated” type system in GraphQL, whereas REST has none - which is what we’re trying to change with this project
• Interestingly, this article says REST has “poor discoverability”, while arguing that GraphQL has good discoverability since it’s “based on relational data”. I would argue that HATEOAS is good enough
• REST is “Thin Client”, which I would argue is a good thing

Versioning and Evolvability

• Uses “Badoo” as a case study, as it ships continuous updates with a “healthy backwards compatibility”

  • Badoo uses GraphQL so that clients can negotiate new fields being added

    I would counter that with my concept of “conversational APIs” - whenever a feature is added, it can be gated behind a flag or a nullable link, and that logic can update server side whenever it needs to.

• It then discusses Spotify, and sort of points at some of the lessons I got from my previous job, which I mostly skimmed over to be honest

Then there’s a whole lot of junk about microservices and serverless architecture.

Then some stuff about “automotive-grade longevity” and IoT security involving “proof of possession” that may be relevant but I also skimmed over

Other bits

• Avoiding “Protocol tunneling”, where URIs can often lose meaning - it seems to be a logging issue