REST URI Design: дополнительная и многозначная передача информации - PullRequest
Новая
       27

REST URI Design: дополнительная и многозначная передача информации

2 голосов
/ 07 мая 2011

У меня есть один виджет поиска, где люди ищут автодилеров по почтовому индексу.Есть также несколько дополнительных флажков для уточнения поиска в этом виджете.

Вот URI для поиска дилера по почтовому индексу.

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

Если пользователь выбирает чекбоксы, тогда URI будет 

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

Я использую Джерси .Вот код 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){
    .. . ..
    }

Это правильный подход для передачи необязательных и нескольких значений и.Кто-нибудь может мне помочь применить лучшие практики?

Ответы [ 3 ]

3 голосов
/ 07 мая 2011

Если вы серьезно относитесь к пониманию и применению REST, я бы порекомендовал прочитать статью REST , если вы еще этого не сделали.

В соответствии с архитектурой, предложенной в этом документе, каждый URL-адрес сопоставляется с ресурсом .Ресурс может быть чем-то внешним и осязаемым, например, автосалоном.Или это может быть что-то «виртуальное», например, «регион», или даже почтовый индекс, который может содержать дилерские центры.

Что касается параметризации запросов, подумайте о том, какой ресурс вы хотите использовать для удовлетворения или предоставления запросов.Почему вы рассматриваете "почтовый индекс" как переменный параметр, иначе, чем, скажем, ваш "тип обслуживания"?Разве они не оба выбирают подмножество дилеров?Подумайте, почему вы отличаете их от других - на это может быть веская причина.

Например, вы можете сделать:

Подумайте о сопоставлении URL-адресов с ресурсами.Может быть так, что два разных URL отображаются на один и тот же «результат».вам нужно решить, подходит ли вам это.

Также прекрасно можно получить ресурс и затем выполнить запросы к нему на стороне клиента.Не вся работа должна выполняться сервером.Вы можете искать результаты, полученные с помощью http://server/dealer/zip/10070 на стороне клиента, чтобы найти те, которые предоставляют желаемые услуги.Это может или не может быть выигрыш в производительности, в зависимости от размера передаваемых данных и частоты и разнообразия запросов.

Если предположить, что общий набор результатов равен 10 (скажем, десять дилеров в почтовом индексе), цикл foreach Javascript для поиска дилера, предлагающего услугу X, будет быстрее, чем дополнительный вызов AJAX, запрашивающий сервер выполнитьэтот запрос от имени клиента.

3 голосов
/ 07 мая 2011

Я не уверен, что сопоставил бы поиск дилеров по определенному почтовому индексу с ресурсом;это не совсем правильно.Вместо этого у меня был бы ресурс, в котором перечислены все дилеры, а отдельные дилеры являются субресурсами этого.Если бы можно было вернуть подмножество списка подресурсов, ограниченных свойствами (например, их почтовый индекс), то это было бы отличным способом для осуществления поиска, иначе у меня был бы отдельный обработчик поиска, который возвращает список ссылок.к соответствующим ресурсам дилера. 

@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) { ... }
}
1 голос
/ 07 мая 2011

Это нормально, если ваш URL не становится слишком длинным (хотя длина URL не ограничена какой-либо спецификацией, некоторые браузеры и посредники ограничивают его, поэтому рекомендуется не превышать 1 КБ)

Если он становитсяслишком долго, вы можете использовать POST вместо GET.

PS В вашем коде есть ошибка, она должна быть @QueryParam("servicetype") List<String> servicetype), чтобы соответствовать URI примера.

...