Question

我们目前正在考虑如何为其他系统设计界面。

我的同事希望实现一个通用接口（例如doIt（JSONArray）），您可以在JSONObject中放置想要执行的所需信息，以便调用例如看起来像这样： doIt('{"method":"getInformation", "id":"1234", "detailLevel": "2"}') doIt('{"method":"getEmployeeInfo", "EmployeeId":"4567", "company": "Acme Inc."}')

（我在本例中使用'和'仅用于演示目的。我知道我必须逃避“在实际系统中”。然后可以通过http访问此方法，以便我希望http://mysite/doIt?parm={JSONObject}

我的方法是使用不同的接口及其各自的参数，以便我有一个getInformation(1234,2)和一个getEmployeeInfo(4567,"Acme Inc.")接口。因此，对于通过http访问我的方案看起来像：http://mysite/getInformation?id=1234&detailLevel=2和http://mysite/getEmployeeInfo?employeeId=4567&company=acmeinc.

对于访问我们服务的客户，我们希望提供封装bevahiour的特殊库。例如。将有一个客户端java-lib将客户端调用getEmployeeInfo（..）转换为

http://mysite/doIt?parm={'{"method":"getEmployeeInfo", "EmployeeId":"4567", "company": "Acme Inc."}'}

或

http://mysite/getEmployeeInfo?employeeId=4567&company=acmeinc.

然后返回结果。

因此，对于客户来说，如果后端使用处理“翻译”的库，后端的工作方式将完全透明。

您认为每个想法的利弊是什么？我更喜欢我的方法，因为它看起来“更干净”。但这只是一种难以争辩的感觉。也许你可以给我（或他）一些关于设计和触摸区域（可扩展性，安全性......）的想法，或提供有关此事的有用链接

Answer 1

我可能会投票支持JSON解决方案，即使它们或多或少相同。（两种易于扩展，标准，面向未来的解决方案。）

选择JSON的原因：

对于不同的平台，有许多不同的库可以帮助您构建正确的对象，检查字符串数据是否有效等。
将JSON数据解组为对象。某些库（例如Gson）可以自动封送JSON并将其解组为对象。使您免于编写自己的代码，并获得使用已经过其他人测试的代码的好处。
支持新界面。假设您将传输方法更改为套接字，ftp（！）或其他任何内容。您仍然可以使用其他传输将JSON对象发送给您。

Answer 2

JSON解决方案可能更好，因为您可以更轻松地发送复杂对象

但是这里只是一个小的语法细节，让老板选择（或投票）并构建你的软件。

Answer 3

我意识到这个问题很旧，但是我认为这里的答案将引导开发人员走错路。

根据我的经验，您应该始终倾向于更具体的方法。通用方法难以测试，难以折腾，并且不提供（或最少提供）IDE /编译器支持。您正在描述的此类api不会告诉用户有关它将执行的操作。

您自己建议的api设计要好得多。

话虽如此，这是一种平衡行为。

接口设计/ API设计：通用方法与特定方法

3 个答案: