小编Myo*_*bis的帖子

我想在用户输入后立即对文本框控件的每次修改运行一个函数.该事件.keyup()对于大多数的情况是好的.

但是,浏览器(如Chrome或Firefox)可能会建议文本框控件的自动完成条目(可能是因为输入控件的@name或@id已知).

不幸的是,当"点击建议的条目"时,我无法触发以下任何事件.(.keyup()在使用键盘选择时触发)

$('input#email')
  .click(function() { console.log('click'); })
  .keyup(function() { console.log('keyup'); })
  .keydown(function() { console.log('keydown'); })
  .change(function() { console.log('change'); })
  .focus(function() { console.log('focus'); })
  .blur(function() { console.log('blur'); });

我想尽可能避免使用setInterval()定期检查.

有没有办法检测到这个"选择建议"事件？

我正在通过Http设计类似REST的API.

我需要API客户端(应用程序,而不是浏览器)来关注链接(HATEOAS),而不是构建它们.
此外,由于某些可能不同意的原因,我仍然会使用可读的URL .但是,如果存在相当的方式文档的URL模板(像 这些 的人),我不认为这是正确的做法,因为它可以清楚地吸引和合法的开发人员可以构建自己的网址.

那么,如何以尊重HATEOAS的方式记录API？

我们经常发现与HATEOAS相关的可发现性.
说实话,我不认为这在现实生活中是不够的:商业概念是多重的,微妙的理解和客户开发人员不是你的队友.
有意义的名字显然是不够的.

开发人员需要制作客户端应用..

1. 从条目URL 导航到相关文档的API
2. 构建有效的请求(参数和实体)并解释响应,而不会在语义上产生歧义.

那么,如何记录这个？

• 是否存在以这种方式生成文档的现有工具？
• "词汇表"是否足以填补可发现性和明确解释之间的差距？
• 也许API的HTML表示(Accept:text/html)可以返回人类可读的文档......
• ..对此有任何其他想法或经验吗？

相关概念:
使用Intent,Versioning,Level 3 API进行设计