Hacker News new | past | comments | ask | show | jobs | submit login

There were a couple of additional overlapping factors that contributed to the rise of the FIOH crowd and misinterpretation/misuse of REST and HATEOS:

1. the growing popularity of AJAX and SPA frameworks

2. the rapid growth in mobile clients

We had to make a lot of trade-offs from ideal REST/HATEOS architectures to support these new clients.

Eventually for some it wasn't enough. Facebook launched GraphQL in response to the problems with REST-based APIs they perceived for mobile clients. Fast forward to today and we're walking back to the RPC protocol era.

The problem I have with this advice of, "choosing the right architecture for your application," is that it encourages an ecosystem of competing protocols. Exactly what made the prior RPC-era so annoying... not only was SOAP incredibly bloated and hard to deal with but every services that implemented it also implemented their own snowflake version of it with it's own errors and interpretations. Even if you had a "compliant" SOAP client it was likely that it would be incompatible with your service providers' service in some undocumented way.

At least with FIOH-style APIs you just have to deal with their inane reasoning for return "200 OK: Error" responses and not implementing HATEOS.




Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: