什么是“正确的”？以及保持 Jersey 客户端 API 函数和 REST（Jersey API）服务器函数链接的正确方法？
我想知道拥有更多经验和更复杂项目的人们如何应对 REST 通信中的这种“丑陋”。想象一下以下问题：
我们的 REST 基础设施中的一个特定资源需要相当多的功能，在我的例子中，大约有 50 多个功能，这些功能会导致不同的查询和不同的响应。我试图想出一个有意义的资源树，并将它们分配给可以做“事情”的方法。之后，服务器资源类看起来像这样：
@Path("/thisResource")
public class SomeResource {
@GET/POST/PUT/DELETE
@Path("meaningfulPath")
public Response resourceFunction1 ( ...lots of Params) {
... logic ....
}
//
// lots of functions ...
//
@GET/POST/PUT/DELETE
@Path("meaningfulPath")
public Response resourceFunctionN ( ...lots of Params) {
... logic ....
}
}
为了构造我的客户端将调用的 url，我做了一个小函数来防止打字错误并更好地使用常量，
所以我的客户端看起来像这样：
public class Client() {
public returnType function1 () {
client.resource = ResourceClass.build(Constants.Resouce, "meaningfulPath");
...
return response.getEntity(returnType);
}
}
现在困扰我的问题是如何我把客户端功能和服务器功能联系起来比较好？
这两块代码之间的唯一联系是由客户端调用并由服务器映射的 URL，如果这个 URL 是在其他地方生成的，这会导致很多混乱。
当我的一位同事需要研究这段代码时，他很难弄清楚 50 多个客户端函数中的哪一个会导致哪个服务器函数。而且很难确定代码中是否存在过时的函数等等。我想你们大多数人都比我更了解不干净代码的问题。
你如何处理这个问题？你如何保持这段代码干净、可维护且美观？
I was wondering how people with more experience and more complex projects get along with this "uglyness" in the REST Communication. Imagine the following Problem:
We'll need a fair amount of functionalities for one specific resource within our REST Infrastructure, in my case that's about 50+ functions that result in different querys and different responses. I tried to think of a meaningful resource-tree and assigned these to methods that will do "stuff". Afterwards, the Server Resource Class looks like this:
@Path("/thisResource")
public class SomeResource {
@GET/POST/PUT/DELETE
@Path("meaningfulPath")
public Response resourceFunction1 ( ...lots of Params) {
... logic ....
}
//
// lots of functions ...
//
@GET/POST/PUT/DELETE
@Path("meaningfulPath")
public Response resourceFunctionN ( ...lots of Params) {
... logic ....
}
}
To construct the urls my client will call, I made a little function to prevent Typos and to take better use of Constants
so my Client looks like this:
public class Client() {
public returnType function1 () {
client.resource = ResourceClass.build(Constants.Resouce, "meaningfulPath");
...
return response.getEntity(returnType);
}
}
Now the questions that bothers me is how could I link the client function and the server function better?
The only connection between these two blocks of code is the URL that will be called by the client and mapped by the server, and if even this URL is generated somewhere else, this leads to a lot of confusion.
When one of my colleagues needs to get into this code, he has a hard time figuring out which of the 50+ client functions leads to wich server function. Also it is hard to determine if there are obsolete functions in the code, etc. I guess most of you know about the problems of unclean code better than I do.
How do you deal with this? How would you keep this code clean, maintainable and georgeous?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
通常，这可以通过 EJB 或类似技术来解决。
或者至少通过“真正的”Web 服务，它至少提供 WSDL 和模式 (具有到 Java 接口或“端口”的映射）。
但 REST 通信是非常松散类型和松散结构的。
我现在唯一能想到的是：定义一个项目（让我们称之为“定义”），它将被客户端和服务器引用（因此已知）。在这个项目中，您可以定义一个包含大量
public static final String的类，例如：注意：
static final String可以很好地由注释引用（在在这种情况下，编译器认为它是常量）。因此，请使用“常量”来注释您的@Path，例如：客户端相同：
Normally, this would be addressed by EJB or similar technologies.
Or at least by "real" web services, which would provide at least WSDL and schemas (with kind of mapping to Java interfaces, or "ports").
But REST communication is very loosely typed and loosely structured.
The only thing I can think of now, is: define a project (let's call it "Definitions") which would be referenced (hence known) by client and server. In this project you could define a class with a lot of
public static final String, such as:Note: a
static final Stringcan very well be referenced by an annotation (in that case it is considered to be constant by the compiler). So use the "constants" to annotate your@Path, such as:Same for the client:
您错过了 REST 背后的想法。您所做的不是 REST，而是 RPC over HTTP。一般来说，您不应该使用带外知识来构造 URL。相反，您应该跟踪从服务器收到的响应中收到的链接。了解 HATEOAS：
http://en.wikipedia.org/wiki/HATEOAS
You are missing the idea behind REST. What you are doing is not REST but RPC over HTTP. Generally you are not supposed to construct URLs using out of band knowledge. Instead you should be following links received in the responses received from the server. Read about HATEOAS:
http://en.wikipedia.org/wiki/HATEOAS