REST URI 设计：可选和多值信息传递

发布于 2024-11-06 03:30:41 字数 792 浏览 1 评论 0原文

我有一个搜索小部件，人们可以通过邮政编码搜索汽车经销商。还有一些可选的复选框可以优化该小部件中的搜索。

这是通过邮政编码搜索经销商的 URI。

http://localhost:8080/dealer/zip/10080

如果用户选择复选框，则 URI 将是

http://localhost:8080/dealer/zip/10080servicetype=type1&servicetype=type2&servicetype=type3

我正在使用 jersey。这是java代码。

@Path("/dealer")
@Produces(MediaType.APPLICATION_JSON)
public class DealerLocatorRS {
    private DealerService dealerService=new DealerService();

    @GET
    @Path("/zip/{zip}")
    public List<Dealer> getByZip(@PathParam("zip") String zip, 
        @QueryParam("servicetype") List<String> servicetype){
    .. . ..
    }

这是传递可选值和多个值的正确方法吗？有人可以帮助我应用最佳实践吗？

原文

I have one search widget where people search for car dealers by zip code. There are also some optional checkboxes to refine search in that widget.

Here is the URI for searching dealer by zip code.

http://localhost:8080/dealer/zip/10080

If user selects checboxes then the URI will be

http://localhost:8080/dealer/zip/10080servicetype=type1&servicetype=type2&servicetype=type3

I am using jersey. Here is java code.

@Path("/dealer")
@Produces(MediaType.APPLICATION_JSON)
public class DealerLocatorRS {
    private DealerService dealerService=new DealerService();

    @GET
    @Path("/zip/{zip}")
    public List<Dealer> getByZip(@PathParam("zip") String zip, 
        @QueryParam("servicetype") List<String> servicetype){
    .. . ..
    }

Is this right approach to pass optional and multiple values and . Can anybody help me to apply best practices?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

画中仙 2024-11-13 03:30:41

我不确定是否会将特定邮政编码的经销商搜索映射到资源；感觉不太对劲。相反，我有一个列出所有经销商的资源，其中各个经销商是该资源的子资源。如果可以返回受属性（例如，邮政编码）限制的子资源列表的子集，那么这将是实现搜索的好方法，否则我将有一个单独的搜索处理程序来返回链接列表匹配经销商资源。

@Path("/dealer")
public class Dealers {
    @GET
    public List<Dealer> getAll() { ... }
    @GET
    @Path("search/byZip")
    public List<URI> getByZip(@QueryParam("zip") String zip, ...) { ... }
    @Path("{dealerId:[^/]+}")
    public Dealer getDealer(@PathParam("dealerId") String id) { ... }
}

I'm not sure that I'd map a search for dealers in a particular zip code to a resource; it doesn't feel quite right. Instead, I'd have a resource that lists all the dealers, with individual dealers being sub-resources of that. If it was possible to return a subset of the list of subresources restricted by properties (e.g., their zip code) then that would be a great way to implement a search, otherwise I'd have a separate search handler that returns a list of links to matching dealer resources.

@Path("/dealer")
public class Dealers {
    @GET
    public List<Dealer> getAll() { ... }
    @GET
    @Path("search/byZip")
    public List<URI> getByZip(@QueryParam("zip") String zip, ...) { ... }
    @Path("{dealerId:[^/]+}")
    public Dealer getDealer(@PathParam("dealerId") String id) { ... }
}

回复收藏 0 原文

零崎曲识 2024-11-13 03:30:41

如果您认真了解和应用 REST，我建议您阅读 REST paper，如果您还没有这样做的话。

根据该论文提出的架构，每个 URL 映射到一个资源。
资源可以是外在的、有形的东西，比如汽车经销商。或者它可能是“虚拟”的东西，例如“区域”，甚至可能包含经销商的邮政编码。

至于如何参数化查询，请考虑您想要使用什么资源来满足或公开查询。为什么您将“邮政编码”视为可变参数，与您的“服务类型”有什么不同？他们不都是选择经销商子集的资格吗？想想为什么你要让它们与众不同——可能有一个很好的理由。

例如，您可以这样做：

http://server/dealer/zip/10070
列出 10070 中的所有经销商
http://server/dealer/service/transmissions
列出所有从事变速箱工作的经销商
http://server/dealer/service/transmissions/zip /10070
列出 zip 10070 中从事传输工作的所有经销商
http://server/dealer/zip/ 10070/服务/传输
列出 zip 10070 中从事传输工作的所有经销商
http://server/dealer/service/变速箱/服务/轻型卡车
列出所有从事变速箱工作和轻型卡车服务的经销商

考虑 URL 到资源的映射。两个不同的 URL 可能映射到相同的“结果”。您需要决定这是否适合您。

检索资源然后在客户端对其进行查询也是完全可以的。并非所有工作都需要由服务器完成。您可以在客户端搜索 http://server/dealer/zip/10070 得到的结果，找到提供所需服务的服务。这可能会也可能不会带来性能提升，具体取决于传输数据的大小以及查询的频率和种类。

假设总体结果集为 10 个（例如，一个邮政编码内有 10 个经销商），则搜索提供服务 X 的经销商的 Javascript foreach 循环将比要求服务器代表该经销商执行该查询的附加 AJAX 调用更快。客户。

If you are serious about understanding and applying REST, I'd recommend reading the REST paper, if you haven't done so yet.

According to the architecture proposed in that paper, Each URL maps to a resource.
A resource could be something extrinsic and tangible, like a car dealership. Or it could be something "virtual" like a "region", or even a zipcode that might contain dealerships.

As to how you parameterize queries, think about what resource you want to use to satisfy or expose the queries. Why would you treat "zipcode" as a variable parameter, any differently than, say your "servicetype"? Are they not both qualifiers to select a subset of dealerships? Think about why you are making them different - there may be a good reason.

For example, you could do:

http://server/dealer/zip/10070
list all dealers in 10070
http://server/dealer/service/transmissions
list all dealers that do transmission work
http://server/dealer/service/transmissions/zip/10070
list all dealers that do transmission work in zip 10070
http://server/dealer/zip/10070/service/transmissions
list all dealers in zip 10070 that do transmission work
http://server/dealer/service/transmissions/service/lighttrucks
list all dealers that do transmission work and do light truck service

Think about the mapping of URLs to resources. It may be that two distinct URLs map to the same "result". you need to decide whether that's appropriate for you.

It's also perfectly fine to retrieve a resource and then do queries on it on the client side. Not all work need be done by the server. You could search through the results obtained by http://server/dealer/zip/10070 on the client side, to find the ones that supply the desired services. This may or may not be a performance win, depending on the size of the data transmitted and the frequency and variety of queries.

Supposing an overall result set of 10 (say, ten dealers within a zipcode), a Javascript foreach loop searching for a dealer that offers service X is going to be faster than an additional AJAX call asking the server to do that query on behalf of the client.

回复收藏 0 原文