I am trying to build a Spring REST Read operation using spring boot. Typically for all read only operations preference should be HTTP GET only.. (at least as far as I know)
Scenario: Client will be sending a list of UUID(assume it as employeeID) values to read employee data. Here Client has a provision to select a bunch of employees and read the data.
Once request is received I need to iterate through those IDs and invoke an existing third party service which will give me the employee data.
Once all UUIDs are processed a report will be generated for all those selected employees.
List of items I would like to hear from you all is..
How to achieve GET operation here when incoming IDs are more than HTTP GET URI limit. Because if the IDs are 100 then the URI is going to reach the limit.
Please request to not suggest for HTTP POST because of few limitations in the requirement.
Any references for handling this scenario asynchronously is much appreciated.
If you suggest to store the IDs first into a table and process them later.. Sorry this is not something what I am looking for. Because client need this data in less than 10 seconds.. (approx)
How to achieve GET operation here when incoming IDs are more than HTTP GET URI limit. Because if the IDs are 100 then the URI is going to reach the limit
Instead of sending these IDs in URI, add these IDs in request body send with GET request.
HTTP GET with request body
You can totally send the UUID's as a request body with GET call. It works just fine.
Ok you are very restricted but I can see that there are two ways to face it, group them or send them by parts then my suggestions are:
I read number 4 but you can improve your requests and time execution sending async requests, then you can send a segment with a ID and total of UUID's to get all information in a short time in server, then you could process it.
Make segments of UUID's to identify them by groups and not individually, then your UUID's will be few.
I don't know if you can get a "selected event" with a check box to send a request for every event, when user sends "generate report event" then you has all data in server.
Related
I have got a simple CRUD application - get some entities, convert it to DTO and send via REST controller.
I want to search by the field, that is not unique, but really rarely recurring. So when I send POST with 'field':'123' - my app return only 2 records.
The question is why when I send ?sort=someFiled%2Cdesc&size=10000&page=0the request take a really long time (~900ms), but when I send it with size=10, the request duration is ~150ms? When the result is only 2 fields, I thought that the request should take the same time for many sizes.
Tested on my remote machine, because locally the time was to short to compare it.
Is this a spring problem?
I'm working with a web application that has a javascript front-end and Tomcat/java server. The front-end is simply a table where the user can modify the table and add more rows and fill out the form. I wrote some code so that the user can save the table. It sends the data in the form to the server through an http request, the server writes the data to an oracle database, everything works great.
As the table grows however, it is no longer feasible to send it all in one request. One suggestion was to split the rows up into different requests, but then if one request succeeds and another fails the oracle table will be incorrect.
What is the preferred method to send the server multiple chunks of data while the server does not begin to work on it until all the data has been received? I've seen plenty of SO questions about TCP connections regarding data chunking, but not really around http requests.
Thanks.
Why are you trying to send the whole table on each request? Just send the difference. I assume that you have ids for the rows or some identifier. Send the list of ids of deleted rows, list of new rows and list of updated rows. That way, you won't have to send all table data.
Do you really need to send the entire table every time user changes it? Why not simply create an API which allows you to modify just the rows which were modified? It seems its much better solution. This way, the client will send only the relevant data, e.g. the single added/modified row.
I am new to restful services and willing to get some ideas from the experts.
The application which will be accessing my service is having a datatable-grid (each row of the grid represents an Employee Object/Entity) where user can delete more than 1 records at a time(based on the number of checkbox selected by the user). In such kind of a delete operating how will be the URL representation and how will the data be send to the service?
My Idea
Since the number of rows deleted by the differs (based on the number of checkbox selected by the user), hence I am opting for the query string and below will be the URL representation using which I can get the data in my service:
/deleteEmployees?id=1,2,3
i.e. a comma seperated values of the id's which will uniquely identify a record in the table.
Based on my Idea, I have a few questions:
1) The query String mentioned above contains of comma-seperated values (i.e. Ids). Is it a valid URL where query strings will contain this kind of values?
2) Is there any restrictions in defining the query strings of an URL (like the way I did using csv)?
3) Any other alternative of achieving the same in a better and efficient manner?
P.S. I am new on this and hence looking for different ideas from the experts and try to understand what is correct and what is not.
A comma separated list of Employee ids is a fine way to do it, but I wouldn't put it in a URL with an action in it, ie. /deleteEmployees?id=1,2,3. REST is more about identifying resources, rather than actions, in URLs. I would either loop through each one of the employee ids to delete and send an HTTP DELETE request for each
DELETE /employees/1 HTTP/1.1
DELETE /employees/2 HTTP/1.1
DELETE /employees/3 HTTP/1.1
Another alternative is to send one HTTP DELETE request to a URL like /employees, keeping the suggested REST identification of resources and using HTTP methods. You would pass the list of ids in an HTTP header.
DELETE /employees HTTP/1.1
Employees-To-Delete: 1,2,3
Take a look at this answer for character restrictions in URLs.
I am curious if there is a way to store some user data on my request which will come back to me on the returned data. For example, I am sending several requests for let's say 3 different orders. They might be for the same symbol, but depending on the order I will be getting different types of data. Is there a way that I store the order ID on the outgoing message request and have it come back to me on the return? I see there is a Session.sendRequest call where you can specify a requestLabel, but I don't see it coming back on the returned message so I'm not sure what this is for.
Thank you in advance!
It looks like the correlation ID is exactly what is needed. I can create a unique correlation ID for each order request based on the order ID and some unique string (for me, a count is sufficient). Then I can parse out the order ID piece when it is returned. I'm still not fully sure what requestLabel is for, but I don't think I need it for this requirement.
I think it'd be up to you and your app, not Bloomberg. I'll bet Bloomberg is idempotent - it treats every request that comes in as if it's the first one ever.
The Session is a variable on your side that's created when a user logs in. You'd create the label or some other unique tracking GUID and keep it in session. Every request that user sends out during that Session would be associated with that session ID>
Scenario Imagine a REST service that returns a list of things (e.g. notifications)
Usage A client will continually poll the REST service. The REST service retrieves records from the database. If records are available, they are converted into JSON and returned to the client. And at the same time, the retrieved records are purged from the DB.
Problem How do you handle the problem if the REST endpoints encounters a problem writing the results back to the client ? By that time, the records have been deleted.
Deleting the records will always be a dangerous proposition. What you could do instead is include a timestamp column on the data. Then have your REST url include a "new since" timestamp. You return all records from that timestamp on.
If the notifications grow to be too large you can always setup an automated task to purge records more than an hour old - or whatever interval works well for you.
It sounds like a strange idea to delete DB records after reading access. Possible problems immediately leap into mind: Network trouble prevent the client reading the data, multiple clients cause each other to see incomplete lists, et.al.
The RESTful apporach might be like this:
Give each notification a specific URI. Allow GET and DELETE on these URIs. The client may trigger the record deletion once it successfully received and processed the notification.
Provide an URI to the collection of current notifications. Serve a list of notification data (ID, URI, timestamp, (optional:) content) upon GET request. Take a look at the Atom protocol for ideas. Optional: Allow POST to add a new notification.
With this approach all reading requests stay simple GETs. You may instrument the usual HTTP caching mechanisms on proxies and clients for performance improvement.
Anyway: Deleting a DB entry is a state change on the server. You must not do this upon a GET request. So POST will be you primary choice. But this does not help you much, since the communication might still not be reliable. And polling qith POSTs smells a lot more like Web-Services than REST.
This could be a possible solution.
The REST service can query the database for a list of notifications.
It marks each item in the list ,by say setting a flag in the database.
It then delivers all this notification records to the client.
If the server has successfully sent the results to the client, all marked records are deleted.
In case of failure, the marked records are unmarked,so that they get delivered during the subsequent polling interval.
I hope you got my point.
We did this with special timestamp paramter.
Requests
Request with timestamp.min, this return all items, and server timestamp;
Request with timestamp from server, return items from hat time stamp, and delete prevoius, return server time stamp;
Please note that we did all this with post. means that virtually we sent command (not query get).