Swagger UI custom order of endpoint parameters - spring

As we can see spring orders parameters by the name alphabetically.
I'd like to provide a custom order like in the #ApiModel class.
So fromLocation should be the last.
How can I achieve this?

It looks like this is not possible on Springfox and since the move to Java 8 it is alphabetically ordered:
What we discovered when moving to java 8 compiler was that the order changed. When we realized that was the case, the parameters were changed to being alphabetically sorted
More details: https://github.com/springfox/springfox/issues/2418

Related

JHipster friltering in CRUDs pages

i'm ramping up in JHipster, and i'm trying this approach: use the generated pages and code to earn development time.
I have a requirement to filter entities/tables content for certain fields/column within CRUDs. Another requirement is not to use Elasticsearch.
My idea is to add filtering fields to those pages and use the generated classes entityCriteria.java to filter data.
I don't know how to map search criterion to that class, from the entity.component.ts script.
I can add criteria programatically, but i think is good idea to modify only that and, as i allready says, earn a lot of development time.
Can anyone orient me on the right direction?
Thanks in advance
I solved adding the filter fields to the controller and the page. Also add an initialization for each field in the constructor.
The filter criteria is added in the loadAll method.
Just like that.

Spring Data Rest: pass Collection<Entity> as query String parameter

First off, this is related to Spring Data Rest: How to search by another object's key? which appears to be resolved in https://jira.spring.io/browse/DATAREST-502
My issue is (I believe) and extension of this. I'm seeing the following behavior:
I have two repository queries defined e.g.
Person findByAccount(#Param("account") Account account));
Collection<Person> findByAccountIn(#Param("accounts") Collection<Account> accounts));
Both search methods are exposed via spring-data-rest. I can access the first using a url such as http://localhost:8080/people/search/findByAccount?account=http://localhost:8080/accounts/1
I can access the second method using a url such as http://localhost:8080/people/search/findByAccountIn?accounts=http://localhost:8080/accounts/1, but if I try to pass in MULTIPLE accounts, such as
http://localhost:8080/people/search/findByAccountIn?accounts=http://localhost:8080/accounts/1,http://localhost:8080/accounts/2,
It will run the query except will IGNORE the first account (http://localhost:8080/accounts/1) and only search based on the second (http://localhost:8080/accounts/2)
What is the proper technique for passing in a Collection of entities to a repository argument over the REST API? I find it works great for a single entity, but not for a Collection. Note that both of these repository methods are working as expected when directly accessing the JpaRepository.
Also note that these queries seem to work if the collection is of some primitive type, for example findByAccountIdIn(#Param("accountIds") Collection<Long> accountIds) is accessible with intended functionality via http://localhost:8080/people/search/findByAccountIdIn?accountIds=1,2. This leads me to believe it's possibly an error in the way a list of URIs is passed into a query method which expects a Collection of corresponding entities.
Thanks in advance for any help!
Try repeat the query parameter as most servers will interpret this as a list. It might not be the prettiest solution but should work.
http://localhost:8080/people/search/findByAccountIn?accounts=http://localhost:8080/accounts/1&accounts=http://localhost:8080/accounts/2
I know that this is forever old, but I found the answer.
I will put this here for anyone else who should wander this way:
How to use List in endpoint exported by Spring Data REST?
List<Person> findByAccountIn(#Param("accounts") Account... accounts);
the request would look like this:
http://localhost:8080/people/search/findByAccountIn?accounts=http://localhost:8080/accounts/1&accounts=http://localhost:8080/accounts/2&accounts=http://localhost/accounts/anotheraccountid

REST sort descending with minus ('-') symbol, rather than <propertyName>.dir=desc

I'm trying out Spring Data with MongoDB and REST as shown here. One thing I noticed is that to sort results, you add a query parameter named .dir with a value of "asc" or "desc".
In many REST APIs I've used, the mechanism for sorting was to simply put a minus ("-") symbol in front of the property name in the sort (or order) parameter.
Is there any way I could customize Spring to allow for this behavior?
I remembered I stumbled on this thread before I made the customized resolver. You can use SimpleSortHandlerMethodArgumentResolver class on https://github.com/sancho21/spring-data-commons/commit/6c90a9cfcb50b2ed0e7a25db0cfd64d36e7065da
Please comment to support its adoption on https://github.com/spring-projects/spring-data-commons/pull/166/files
As for reminder, in order to use this class, you need to inject an instance of it into the existing the constructor of existing PageableHandlerMethodArgumentResolver instance.

Best way to represent object views (summary, detail, full etc) in Spring based REST service

I am working on a REST service which uses Spring 4.x. As per a requirement I have to produce several different views out of same object. Sample URIs:
To get full details of a location service: /services/locations/{id}/?q=view:full
To get summary of a location service: /services/locations/{id}/?q=view:summary
I have thought of two solutions for such problem:
1. Create different objects for different views.
2. Create same object, but filter out the fields based on some configuration (shown below)
location_summary_fields = field1, field2
location_detail_fields = field1, field2, field3
Could someone help me to understand what could be an ideal solution? I am not aware of any standard practice followed for this kind of problems.
Thanks,
NN
In my opinion the best option is to use separate POJOs for different views. It's a lot easier to document it (for example when you use some automated tools like Swagger). Also you've to remember that your application will change after some time, and then having one common POJO could make troubles - then you'll need to add one field to one service and don't expose it through another.
See this article on how google gson uses annotations to convert a Java Object representation to a json format : http://www.javacreed.com/gson-annotations-example/
Since you want two different representations for the same object you could roll your own
toJson method as follows :
a) Annotate each field of you model with either #Summary, #Detail or #All
b) Implement a toJson() method that returns a json representation by examining the annotations for the fields and appropriately using them
If you need an XML representation same thing, except you would have a toXML().

Validate a Collection Has at Least One Item using Validation Application Block

Using the Enterprise Library 4.1 Validation Application Block, how can I validate that a collection property contains at least one item?
I'm assuming you mean out of the box. If so, then I don't think there is way to validate directly the number of items in a collection.
These are some other ways that you could try:
Decree that you only deal with null collections and not empty collections and use a Not Null Validator. Not practical, though.
Use self validation and have the object validate in code that the collection(s) have the correct number of items. Will work but it's nice to have the validation in the configuration file.
Expose the collection count as a property. This could be done, assuming an employee collection for example, with an EmployeeCount property on your object that contains the collection or you could create your own custom collections that expose a count property. Then you could use a Range Validator to validate on the Count property.
Create a custom validator that can validate the number of items in a collection -- something like CollectionCountRangeValidator.
If I wanted to develop something quickly, I would probably go with option 3. However, option 4 fits in well with the Enterprise Library approach and also allows your class design to be independent of the validation requirements. Plus you could always reuse it on your next project. :) And does anyone really miss creating their own collections when a List will do nicely?
This is already implemented in the EntLib Contrib.
This is called CollectionCountValidator.

Resources