The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

144535 (1) [Avatar] Offline
#1
Unfortunately, in a similar way the word "service" in our industry has become a catchall amorphous concept, the term REST has lost its original meaning in common usage. The second paragraph of section 1.1.1 (page 3) refers to “HTTP REST calls” as synonymous to making calls to HTTP-based APIs. I know the paragraph is attempting to clarify what the web has become but I believe this usage is confusing. I would suggest avoiding using the term REST in the context of this paragraph.

While it could be helpful to readers to provide an accurate description of the REST architectural style and how it captures the lessons learned from the creation and development of the original HTTP protocol, it is not essential for content describing HTTP/2. The other usages of the term REST in this book are appropriate in their context and shouldn’t be changed.

Thank you for doing the work to put this book together. I know the ‘what is REST’ wars are over and the common CRUD over HTTP usage won. I hope you don’t take this as someone only being pedantic about REST. I feel a better understanding of REST would actually contribute to better HTTP applications and hopefully your book will contribute to that understanding.

Barry Pollard (25) [Avatar] Offline
#2
Thanks for the feedback and no problem changing the wording of "often through HTTP REST calls" to "often through HTTP calls". I presume that's the bit you were talking about? It doesn't take away from the meaning and in fact more accurately captures the point I was trying to make without limiting them to strictly RESTful APIs. So thanks for that suggestion.

It's a bit late to include a proper definition of REST, as that would be a bigger change and open to arguments I'm not sure I want to get involved in, as you hint at! Plus it's not strictly on topic, as you say. I'm also not sure I'm the right one to state such a definition - oddly for someone so interested in protocols, I'm on the side of being less strict here and think REST would struggle to be used in most contexts if it was so strictly adhered to (and I know I'm opening myself up to arguments here!). But that's possibly also because no other term has stuck for the more generic usage that many (incorrectly) mean when they use the term REST. CRUD APIs seem so database-centric and, Web APIs and HTTP APIs both seem a little too vague. There's something satisfying about the term REST, even when used incorrectly. smilie

Anyway let me know if you spot anything else that could be approved.

Thanks,
Barry