Java JAX-RS：通过查询参数实现多个操作

我有一个支持多个操作a、B和C的服务

每个操作都有不同的参数。我的架构师希望我为每个操作使用以下URL实现这些操作：

http://<server>:<port>/application/service?q=A&<query_paramers>
http://<server>:<port>/application/service?q=B&<query_paramers>
http://<server>:<port>/application/service?q=C&<query_paramers>

http://：/application/service？q=A&
http://：/application/service？q=B&
http://：/application/service？q=C&

i、 他希望我接受操作名作为查询参数，而不是路径参数

现在的问题是每个操作都有相同的基本URL，即

http://<server>:<port>/application/service

http://:/application/service

根据我的理解，如果我需要支持这种格式，那么在我的服务中，它将是一个单独的方法，该方法将作为资源公开，在该方法中，我将根据“q”的值决定调用哪个操作

虽然它看起来会起作用，但我对这种方法不太关心

表示所有三个操作的单个资源将被公开，这在我看来是不正确的。我不确定这方面的行业标准，但我认为在资源和应用程序操作/行为之间应该有一对一的映射

单个资源将获取所有操作的参数，这意味着语法将包含单个资源下列出的所有参数，用户将无法找出哪个参数属于哪个操作

在一个方法中接受3个操作的所有参数的一种解决方法是，我的方法只接受一个@Context-UriContext参数，但在这种情况下，我的语法将不列出任何参数，这同样是错误的，因为用户将根本得不到关于每个操作的可能参数的信息

---

提前感谢。

这三个操作是什么？积垢操作

REST中的查询参数被视为具有规范的GET资源（where子句是特定的）

不建议将所有类型的操作都赋予具有查询参数的同一方法

使用@path更改您的路径。如果希望所有服务托管在同一路径下，则使用Http方法区分操作

如果操作是创建资源

然后使用@POST和资源信息作为参数

如果你想

Create the resource - @POST
retrieve the data   - @GET
update the data     - @PUT
delete the data     - @DELETE

资源：

提供有关HTTP方法的详细信息

给出了如何使用@Path和http方法的示例

---

您的想法是正确的：如果所谓的“架构师”告诉您仅通过

GET

请求（或单个HTTP方法）实现这一点，那么您唯一的方法就是使用单个资源方法，根据参数

q

的值，您可以调用一些不同的方法。 与您的担忧相关：

您将有一个单一的资源方法来处理这三个请求，这是不好的。但是，如果您有一个单一的资源（即类），用三种资源方法处理所有这些请求，那就不坏了

这是正确的。此解决方案的优点是，参数的解组是自动为您进行的（例如，您将直接获得一个长参数或一个枚举，而无需手动解码）

如果使用

@Context-UriInfo-UriInfo

等参数注入一个get参数，则可以从

UriInfo

实例获取所有get参数（请参阅）。缺点是您将手动对它们进行解组，并相应地传递给一些具有清晰签名的私有方法

---

PS：询问您的架构师这样做的原因。如果您更改了数据库中的数据，那么发出GET请求可能不是一个好主意（假设您只是复制URL并将其粘贴到浏览器中）。除此之外，这是一个糟糕的代码，您将调试更多的代码（假设您稍后将得到另外10种情况，除了

q=a、q=b、q=c

）。

所有操作都是get操作。如果需要将它们作为单独的资源实现（使用@Path），我知道应该如何实现，但这里的问题是，如果需要使用查询参数实现它们，如何实现相同的功能。AFAIK，@Path不支持提及查询参数。如果您知道其他选择，请与我们分享。谢谢您提供的信息。即使我使用UriInfo，我的语法也不好看。由于用户将不会获得与特定操作相关的参数的任何信息，并且在语法中，他将看到此资源的单个uriInfo，看起来不太好。是的，资源方法的语法/签名看起来不太好，但该方法可以使用正确的类型/参数调用其他3个方法（带有一个很好的签名）（getQueryParameters（）返回一个

多值Map

）。但这就是我所说的“坏代码”的意思。谢谢你澄清。我将与他讨论这种方法的优缺点，看看他能想出什么。欢迎你。只是不要忘了稍后接受答案。