2016-08-04 6 views
1

Я пытаюсь определить лучший способ взаимодействия с конечной точкой клиента Джерси с переменной Collection<String>. Я не уверен на 100%, что это было бы правильно сделать, но мне было интересно, возможно ли это/что это правильный способ достичь этого - может быть, @POST с телом сообщения?Перегрузка конечной точки REST различными QueryParams

Метод в моем DAO - Set<Foo> retrieveByKeys(Collection<String> keys). В результате я пытаюсь найти лучший способ создания конечной точки для этого. Первая мысль была:

@POST 
@Path('/foos') 
@Consumes(MediaType.APPLICATAION_JSON) 
@Produces(MediaType.APPLICATAION_JSON) 
Response retrieveByKeys(Collection<String> keys) { 
    ... //do things 
} 

ИЛИ:

@GET 
@Path('/foos') 
Response retrieveByKeys(@QueryParam('keys') Collection<String> keys) { 
    ... //do things 
} 

Я не слишком уверен, что вы можете сделать второй, но было предложено в качестве возможного решения.

Это хорошо в любом случае, но в то же время у меня есть другой метод в моем DAO, то есть List<Foo> retrievePageStartingFrom(String startKey, int pageSize). Я знаю, что лучше всего проводить повторные попытки использовать URL-адреса, когда это возможно, и это то, что я пытаюсь сделать с этими двумя. Я просто пытаюсь найти способ дифференцировать два метода, но сохранить один и тот же URL.

мне было интересно, если это возможно перегружать конечную точку с другой @QueryParams, но на этот раз, как:

@GET 
@Path('/foos') 
Response retrievePageStartingFrom(@QueryParam('startKey') String startKey, @QueryParam('pageSize') int pageSize) { 
    ... //do things 
} 

И что Клиент Джерси будет знать, чтобы различать два вызова, так как первый метод имеет один параметр и второй метод также имеет два параметра, которые также являются разными.

Я думаю, что лучший способ, что я думаю, я пытаюсь сделать, это как в java, когда вы можете иметь один конструктор с определенными параметрами и другой конструктор с разными/разными типами параметров, но с тем же именем метода (очевидно) ,

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

ответ

2

Нет, невозможно перегрузить методы конечных точек, если все они используют одни и те же методы HTTP (например, все с аннотацией @Get), но разные параметры запроса. Ресурсы ресурсов уникально идентифицируются URI, а не параметрами.

то, что вам нужно сделать, это проверить наличие различных параметров запроса и вызвать нужную реализацию:

@GET 
@Path('/foos') 
Response retrieveByKeys(@QueryParam('keys') Collection<String> keys, @QueryParam('startKey') String startKey, @QueryParam('pageSize') int pageSize) { 
    List<FooRes> fooResources; 
//check if keys Collection is empty 
if(keys==null||keys.isEmpty()){ 
    if(startKey==null || startKey.isEmpty()){ 
     return Response.status(Status.BAD_REQUEST).build(); 
    }else{ 
     if(pageSize==null||pageSize.isEmpty()){ 
      //set default pageSize 
      pageSize=10; 

      //call your DAO or Repository or Service methods 
     fooResources=foosRepo.partialResults(startKey,pageSize); 
     .... 

     } 
    }else{ 
    fooResources=foosRepo.findByKeys(keys); 
    } 
} 

return Response.ok().entity(fooResources).build(); 
} 

Это сырая идея, которую вы можете сделать свой более ясным, вместо того, чтобы использовать вложенную сеть if..else ..

+1

Итак, чтобы убедиться, что это 1: 1 относительно '@ GET' и' URI'? Но тогда я мог бы называть '@ GET' и' @ DELETE' на том же 'URI'? – erp

+0

@erp Точно, вы поняли. – AsSiDe

+0

Цените помощь. Так что было бы целесообразно сделать это, хотя вместо того, чтобы делать только один URI для каждого '@ GET'.Это то, что я сделал в прошлом, но я просто ищу способы повторного использования URIS теперь, когда я узнал, что это что-то такое: p – erp

1

Самый простой способ сделать это - настроить один общедоступный метод, который обслуживает конечную точку, а затем этот метод вызывать набор частных методов на основе того типа ввода, который вы получаете. В общем, вы должны отделять бизнес-логику от логики контроллера в ваших службах Java-отдыха для таких ситуаций.

Смежные вопросы