2017-04-20 62 views
3

我正在设计RESTful Web服务以公开SOA体系结构中的功能。服务客户登录到企业内部网,拥有客户名称,ID和其他技术信息(与业务无关)。如何使用客户端信息的服务器端日志记录功能设计RESTful服务

我有一个要求,即所有对RESTful服务的调用都必须被记录下来,并且必须包含客户端的“not business”信息(id,应用程序名称,登录用户等)。

我想收集JSON对象“technicalData”中的所有技术信息和另一个JSON对象“dto”中PUT/POST的业务数据(数据传输对象)。

将此信息放入GET,POST,PUT,DELETE的请求正文中是否正确?

这些信息在GET/DELETE身体没有语意的要求,因为它们只用于登录目的see this answer on SO

例子:

GET /books?author=AUTHOR 

{ 
    "technicalData": 
    { 
     "id": "...", 
     "loggedUser": "...", 
     "applicationName": "..." 
    } 
} 

POST /books 

{ 
    "technicalData": 
    { 
     "id": "...", 
     "loggedUser": "...", 
     "applicationName": "..." 
    } 
    "dto": 
    { 
     ... 
    } 
} 

PUT /books/ID 

{ 
    "technicalData": 
    { 
     "id": "...", 
     "loggedUser": "...", 
     "applicationName": "..." 
    } 
    "dto": 
    { 
     ... 
    } 
} 

DELETE /books/ID 

{ 
    "technicalData": 
    { 
     "id": "...", 
     "loggedUser": "...", 
     "applicationName": "..." 
    } 
} 

回答

3

不,您不应该在每个请求的主体中传递该信息。您肯定不应该在GET和DELETE调用中将其传递给电线,因为这违反了规范:

发送GET请求上的有效内容主体可能会导致一些现有的实现拒绝请求。 (RFC 7231

在DELETE请求上发送有效内容主体可能会导致一些现有的实现拒绝请求。 (RFC 7231

这样的元信息属于头文件。想必您使用Authorization标题或其他方式来识别用户?这会给你用户名。如果没有,也许From标题将是一个适当的地方来存储它。也许User-Agent可以用来指定应用程序。或者,看看使用JWT,它可以让你嵌入任意信息。

+0

我认为这是正确的答案,我会接受这一点。最后一个问题是:如果服务提供者已经开发了一个“框架”来读取正文请求的JSON部分中的那些数据?什么是最佳选择:将所有端点更改为POST(违反REST,但考虑到所有请求都是Intranet并且不可索引,可缓存)或迫使提供者遵守更大优点的标准?谢谢您的回答。 – Dinux

+0

您应该在接受其他答案之前留出更多的时间。如果一个人已经被接受,有些人会被劝阻回答。至于你的问题,这是介于基于意见和无法回答之间的问题。我的意见是,如果有一个客户,只有一个客户,你可以做任何你想做的事。我不确定谁是“提供者”在这个问题中,但如果没有那么多的信息,我更喜欢使用标题和/或JWT。 –

+0

你说得过早,但在这种情况下,恕我直言,你给了一个完整的答案,这正是我正在寻找的。事实上,我的客户已经使用JWT令牌,但他决定将所有端点“设计”为POST并将这些数据放在主体中。我对此不满意,但我会活下来。非常感谢。 – Dinux

0

通常称为信息“technicalData “不通过请求调用在客户端和服务器之间共享。你应该只共享一个标识当前会话的请求令牌。令牌将在服务器上与已登录的用户相关,等等......

+0

这是客户的要求。服务驻留在ESB中间件上,该中间件不知道类型,登录的用户,BPM事务ID和其他外部信息。 – Dinux

+0

如果服务不知道类型,用户登录,那么你不应该记录这个信息,但只有IP和时间戳。 – ADIMO

+0

这是客户的要求,我不能说我不想传递已经存在的体系结构规范所需的日志信息。 – Dinux