HATEOAS与大型语言模型的结合使用
我想分享一个观察到的瞬间，算是一个灵光一现的想法。
我遇到的大多数声称自己在“做REST”的开发团队，实际上并没有遵循HATEOAS。根据Roy Fielding的严格定义，他会认为这“并不是真正的REST”。（不过不要被这个话题分散注意力，我不想陷入那个纯粹主义的争论中。）
许多团队没有实施HATEOAS的原因在于，它要求API客户端具备智能和适应能力。客户端需要自行发现“我接下来可以做什么”，并运用逻辑来选择下一步。但许多团队面临紧迫的时间压力，因此将REST简单地理解为“通过HTTP传输JSON，并使用一致的URL模式”要容易得多。
有趣的是：引入大型语言模型（LLM）后，HATEOAS的潜力得以释放。LLM可以做到“愚蠢”的API客户端无法做到的事情：询问“我接下来可以做什么”，然后利用推理来理解这些选项并选择其中一个。
查看原文
Just an observation, a light bulb moment, I wanted to share.<p>Most of the dev teams I've ever encountered who said they were "doing REST" were not actually following HATEOAS. Per a strict reading of Roy Fielding, he would consider that "not really REST." (Now don't get distracted, I don't want to wade into that whole purist debate).<p>The reason many did not do HATEOAS is that it requires the API client to be smart and adaptive. It would discover "ok, what can i do next", apply logic to it, and choose the next step. But many shops were on tight time commitments and it was much simpler to just think of REST as "json over http with consistent url patterns."<p>The cool thing is: With an LLM in the mix, HATEOAS is unchained. An LLM can do exactly what a "dumb" api client cannot: ask "what can i do next", and then use _inference_ to understand those options and select one.