json - RESTful HTTP API标准？

Question

我的任务是详细介绍一个简单的api，我做了一点调查，怀疑我所知道的关于互联网的一切都是错误的。
我在谷歌上搜索的时间比我想承认的要长得多，阅读了很多文章、堆积如山的问题和网站，这些似乎都强烈反对。我承认每个开发人员做事情的方式都不同，但仍然怀疑某个地方有一个官方标准，或者至少有一个通用的最佳实践（尽管不可否认，并不是每个人都遵循任何最佳实践）。
这个api将使用json。我无法改变。
我的本地同行告诉我的（很可能是不正确的）：
http是一个复杂的、过时的野兽，我们应该尽可能少地处理它。它只是一个来回移动json块的工具，在那里会发生魔力。所有数据和元数据都应该在json中，您可以完全按照自己的喜好设置它。
对所有内容使用200状态代码，即使用户的输入有应用程序级别的错误或问题。其他错误代码意味着http操作出了问题——一个灾难性的意外服务器错误，使用了错误的url，诸如此类。
“信封”来自服务器的消息的json数据；具有元数据的json属性，并在一致属性（如“data”）中包含实际的json对象/数组
https是“不错的选择”，但对小项目来说并不重要
对所有内容使用PUT请求
登录以从服务器获取随机的强字符作为访问令牌。服务器存储有关令牌何时过期、用于哪个帐户以及使用它的IP地址的信息。将该访问令牌传递给服务器以进行其他每次调用；客户端不存储密码。
url通常是动词，如/register或/checkout或/changepassword。所有其他需要的数据都在json中。每个操作都有自己的url
根据我的阅读，我认为可能是对的，但不确定
http是神圣的数据结构。头信息和服务器返回代码可以包含任何可能的元数据，并且确实是为此目的而设计的。内容只需要包含应用程序所作用的实际json对象。在json主体中不放任何可能是http元数据一部分的内容。
总是使用https
对于任何可能的错误（表单字段未验证、用户的会话已过期、他们的游戏角色已死亡），发送一个http状态代码。试着根据w3c的描述选择最接近的内容，但真正重要的是在系统中始终如一地使用它。代码应该足以告诉客户端应用程序要做什么（显示用户验证错误并使其修复表单输入，使用户再次登录，将用户带回主屏幕）。如果出现错误，正文将包含有关错误的额外详细信息（如果需要）。
客户端应用程序应在http头中随每个请求传递登录信息。这意味着它需要使用basic auth，这意味着它需要记住用户的密码。
json数据不应该放在“信封”中。没有标准格式，因为内容直接表示给定操作所需的对象，如url、get/post/put/delete组合所示
url往往是名词，比如/user或/shoppingcart。url的子目录引用正在操作的对象id:/user/johndoe或/shoppingcart/12359。url可用于get（retrieve data）post（update data）put（create new data）delete（remove data）的不同操作。
我甚至不确定这两种方法是否完全正确——你能告诉我什么是正式的，或者是最推荐的构造这样一个api的方法的规则吗？

Answer 1

你应该阅读田野调查论文的相关部分，它定义了什么是rest：http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
markus的另一篇论文：http://www.markus-lanthaler.com/research/third-generation-web-apis-bridging-the-gap-between-rest-and-linked-data.pdf他开始了创建标准rest实现的工作：http://www.hydra-cg.com/rdf rest vocab和http://json-ld.org/rdf json格式。目前我们还没有一个标准的解决方案来描述任何rest服务的统一接口。这就像我们没有一个html标准。这就是为什么我们不能只编写特定于应用程序的客户端的rest浏览器。
（hydra还没有准备好生产，我想they还需要2-3年的时间来标准化它，并开始构建hydra特定的工具。在此之前，我们不能真正讨论真正的rest，因为大多数api定义了一种特定于实现的格式，或者使用了一种或多或少通用的非标准格式，比如hal）。