Thoughts on REST, Linked Data, Hypermedia, GraphQL, and gRPC

I'm endlessly fascinated by APIs and enjoy studying their evolution. One of the challenges in helping evangelize APIs that I come across regularly is the many different views of what is or isn't an API amongst people who are API-literate, as well as helping bring APIs into focus for the API newcomers — because there are so many possibilities.

Out of the two, I'd say that dealing with API dogma is by far a bigger challenge than explaining APIs to newbies. Dogma can be very poisonous to productive conversations and end up working against everyone involved in my opinion. 

I'm enjoying reading about the evolution in the API space when it comes to GraphQL and gRPC. There are a number of very interesting implementations, services, tooling, and implementations emerging in both these areas. However, I do see similar mistakes being made regarding dogmatic behavior, aggressive marketing tactics, and shaming folks for doing things differently — as I've seen with REST, hypermedia, and linked data efforts. I know folks are passionate about what they are doing and they truly believe their way is right, but I'm concerned that you will all suffer from the same deficiencies in adoption I've seen with previous implementations.

I started API Evangelist with the mission of counteracting the aggressive approach of the RESTafarians. I've spent a great deal of time thinking about how I can turn average developers and even business folks on to the concept of APIs. No, not just REST or just hypermedia, but web APIs in general — something that I now feel includes GraphQL and gRPC. I've seen many hardworking folks invest a lot into their APIs, only to have them torn apart by API techbros (TM) who think they've done it wrong, not giving a rat's *ss regarding the need to actually help someone understand the pros and cons of each approach.

I'm confident that GraphQL will find its place in the API toolbox and enjoy significant adoption when it comes to data-intensive API implementations. However, I'd say 75% of the posts I read are pitting GraphQL against REST, stating it is a better solution, period, with no mention of its limitations or use cases where it might not be a good idea, leaving us to only find out about these from the GraphQL haters and playing out the exact same production we've seen over the last five years with REST versus hypermedia.

Hypermedia is finding its place in some very useful API implementations like FoxyCart and AWS API Gateway (to name just a few), but its growth has definitely suffered from this type of storytelling — and I fear that GraphQL will face a similar fate. 

This problem is not a technical challenge. It is a storytelling and communication challenge bundled with some very narrow incentive models fueled by a male-dominated startup culture where folks really, really like being right and making others feel bad for not being right. Stop it. You aren't helping your cause.

Even if you do get all your techbros thinking like you do, your tactics will fail in the mainstream business world and you will only give more ammo to your haters — and further confusing you would be consumers, adopters, and practitioners. You will have a lot more success if you are empathetic towards your readers and produce content that educates and empowers over shames and tears down.

I'm writing this because I want my readers to understand the benefits of GraphQL, and I don't want gRPC evangelists to make the same mistake. It has taken way too long for linked data efforts to recover, and before you say it isn't a thing, it has made a significant comeback in SEO circles because of Google's adoption of JSON-LD and a handful of SEO evangelists spreading the gospel in a friendly and accessible way — not because of linked data people.

As I've said before, we should be investing in a robust API toolbox, helping people understand that benefits of different approaches, learning about the successful implementations. Please learn from others mistakes in the sector and help see meaningful growth across all viable approaches to doing API — thanks.