Rest endpoint with variable search criteria - spring-boot

I am writing a Spring Boot rest endpoint that returns data from an Oracle database of 2 tables. I want to allow the client to vary their query parameters. For example, to query on just firstName, just lastName, firstName + lastName, or DOB etc. I want to make it flexible. I don't want to write multiple endpoints to cater for many query permutations; I'd like to write one endpoint with some sort of variable criteria.
I know I can just append to query string in a GET request, e.g. /find?firstName=Joe, lastName=Bloggs, but I'd prefer not to have my parameters in the url (mabe this is the only way?)
I've seen jakarta.persistence.CriteriaBuilder getCriteriaBuilder() used but it seems complicated.
Are there any modern libraries that cater for this design pattern?

Related

How to handle multiple request params in spring boot?

Suppose I have a Employee class. It has got many fields like id, firstName, lastName, designaton, age, salary and other fields too. Now I am making a Get Query where I want to use all of these fields (required=false) to be passed as Request Params.
But the question is, there could be many combinations like (firstName,age) or (age,salary,lastName) or (designation,age,salary,lastName) and many more like this. So how should I handle all this filters. Shall I have to write each query for each case?
PS: I am using Spring Boot with Spring Data Jpa.
For this you will have to send Object from where you can get your combination. There may be many combination. So from this perspective you will send value as object and for database query you will select your combinations from that object.
If you want different combination, it won't be a good practice to write controller for every combination. So you can send a Object instead of RequestParam value where you can get your combinations from the Object
Example :
Class Employee{
// Your class instance variable
// Which is called your combinations
}
public Employee getEmployeeByName(Employee employee){
// now you send your desired combination from employee class for
// database query
}
Where you have too many fields, it's not a good practice to send all fields as RequestParam. Think of your class getting bigger day by day and you editing the controller method continously.
Better way is send as a object. No need to edit controller later. Only change the entity class

URL Naming convention for fetching only a column from resource

I have a microservice endpoint that gets a list of company details from the DB. The URL pattern looks like this.
GET https://example.com/api/v1/companies
I need to develop another URL that fetches only the company names from DB. I understand I can reuse the same URL, but to fetch only one column i don't want to fetch all columns.
Please guide me how to have the url pattern for this case.
Ex: GET https://example.com/api/v1/companies/companyNames?
We should not increase number of services exposed until it is really needed. I will recommend re-using the same service with format:
GET https://example.com/api/v1/companies?col=name
If col parameter is blank you can assume to return all columns. This will help you re-use the codebase; minimal changes; and lots of flexibility in future; and less confusion for end consumer.

GraphQL pre-approved queries

I read that Facebook's internal servers accept any queries in dev
mode, and these are cached. In production, only a pre-approved/cached
query is permitted. This was mentioned as a model which other servers
should adopt.
Does someone know what tools do they use for that? Does this process is described more detailed somewhere?
I don't know how it's down in facebook but I can explain how I did it in GraphQL Guru. As graphql is language agnostic I'll explain without being language specific.
The way persisted queries work is a client sends a query with a unique id and variables to a graphql (persisted query ready) server.
{
"id": "1234",
"varibles": {
"firtName": "John",
"lstName": "Smith"
}
}
For the id don't use a hash of the query as the this results in long id names of varying sizes, which kind of defeats the purpose.
On your server, create a file with the same name as the persisted query id, which contains the actual graphql query. Or save it in a database.
To get the graphql query you will need to intercept it via middleware. The middleware retrieves the graphql query via its id and passes the query on to the graphql endpoint. Depending on how the query was defined the middleware may need to parse it. Also, it is in the middleware where you can whitelist if the persisted query id does not exist.
Then the graphql endpoint process the query as normal.
You can see a nodejs example here https://github.com/otissv/guru-express-server/blob/master/src/routes/graphql-route.js

Having trouble creating a data model design in Parse

I'm having trouble figuring out a data model for my project. I'm using Parse as the backend.
I intend to have users who are in groups, and the groups have text posts. What should be classes, and what should be rows in those classes.
I'm guessing a good way to do this would be, have a group, user, and post class.
The columns for the group class would be: GroupID, GroupName, postID, UserID
The columns for the user class would be: UserID, GroupsUserBelongsTo, user name, password, email
The columns for the post class would be: UserIDPostBelongsTo, GroupID, TextFile, TimeCreated
Is there anything I'm missing, or I should change.
You're thinking is a very SQL / rows based way and you shouldn't, this isn't SQL, it's objects and relationships.
So, your classes are fine, and the actual data is fine, but where you're using ids you should be using relationships. Post should just have a pointer to user. Perhaps, don't bother with a relationship from user to groups (you can query that using the other relationship), though you can, particularly if you will have lots of users / groups.
You may also want to consider roles to provide security for the groups.

RESTful API - validation of related records

I implementing RESTful API service and i have a question about saving related records.
For example i have users table and related user_emails table. User emails should be unique.
On client side i have a form with user data fields and a number of user_email fields (user can add any number of fields independently). When the user saves the form i must first make query to create record in users table to get her ID, ​​and only then i can make query to save user emails (because in now i have id of record which come with response after saving user data). But if user enters not unique email in any field then the request will fail. So I create a record in the users table but not create record in user_emails table.
What are the approaches to implement validation of all this data before saving?
This is nor related restful api but transactional processing on the backend. If you are using Java, with JPA you can persist both element in the same transaction then you can notice if there is a problem and rollback the entire transaction returning a response.
I would condense it down to a single request, if you could. Just for performance's sake, if nothing else. Use the user_email as your key, and have the request return some sort of status result: if the user_email is unique, it'll respond with a success message. Otherwise, it'd indicate failure.
It's much better to implement that check solely on the server side and not both with the ID value unless you need to. It'll offer better performance to do that, and it'll let you change your implementation later more easily.
As for the actual code you use, since I'm not one hundred percent on what you're actually asking, you could use a MERGE if you're using SQL Server. That'd make it a bit easier to import the user's email and let the database worry about duplicates.

Resources