I have a requirement below;
I have a jqgrid that loads the json data using webservice(RESTful webservices) call.When form loads, i hit the server and load the data to grid.If i have 50 rows, the grid is loading 50 rows only.but i used pagination, so it will display only 10 records and click on next button in pagination other 10 records will displayed.But my requirement is on formload i should hit server and restric to display only 10 records.Then i click on Next again i call webservice call and display the next 10 rows.Is it possible?If yes, can share any samples?
Classical RESTful web services don't support pagination. So one have to return all data from the server and to use client side pagination. If you have only 50 rows of data I would recommend you to use client side pagination. You need just include loadonce: true option to the jqGrid and all should already work. In general it's recommended to use loadonce: true option if one loads not so many data from the server. There are not exist the exact limit of rows where client side pagination is preferred. It's about 1000 or 10000 rows of data. So in case of 50 rows of data it's really strictly recommended.
If you really need to implement server side pagination of RESTful services (in case of really large dataset) then your service have to support additional parameters of request which will be have no relation to resource URL. For example Open Data Protocol (OData) URI supports starting with version 2.0 (see here for example) parameters $orderby, $skip, $top and $inlinecount which could be appended to the URL to inform the server to return the data sorted by $orderby. The returned data should contains only one page of sorted data based on the values of $skip, $top parameters. The URL looks like
http://host:port/path/SampleService.svc/Categories(1)/Products?$top=2&$orderby=Name
\______________________________________/\____________________/ \__________________/
| | |
service root URL resource path query options
The old answer provides an example of implementation jqGrid which calls Open Data Protocol (OData) web service. I used serializeGridData callback to fill $top, $skip, $orderby and $inlinecount which "understands" OData web service. I used beforeProcessing callback to total property in based on count property returned from the server because of usage $inlinecount: "allpages" in the request. If the RESTful web services, which you use, supports OData too then you can use the same code.
Related
REST endpoint design says: Not use verb
In an workflow-like create Employee which has multi-tab style like "Basic Details", "Educational Details", "Work Experience", etc... One first tab data is filled continue button is pushed resulting in an backend API call which just validates the detail in that tab and returns the list of validation errors if any or moves to next tab for the user to fill data. So basically this calls for validate API for each of the tabs with no intention of saving data. Now one thing that comes naturally is below:
POST /employee/basic/validate
(removing api versioning details from endpoint for simplicity)
But using validate in API means verb. How to design then?
There's a separate flow where one can just save "basic details" of employee - so its like any normal API validate and save - so POST /employee/basic/ is good for that case.
REST endpoint design says: Not use verb
That's not a REST constraint - REST doesn't care what spellings you use for your resource identifiers.
All of these URL work, exactly the way that your browser expects them to:
https://www.merriam-webster.com/dictionary/post
https://www.merriam-webster.com/dictionary/get
https://www.merriam-webster.com/dictionary/put
https://www.merriam-webster.com/dictionary/patch
https://www.merriam-webster.com/dictionary/delete
Resources are generalizations of documents; the nature of the HTTP uniform interface is that we have a large set of documents, and a small number of messages that we can send to them.
So if you want a good resource identifier, the important thing to consider is the nature of the "document" that you are targeting with the request.
For instance, the document you are using to validate user inputs might be the validation policy; or you might instead prefer to think of that document as an index into a collection of validation reports (where we have one report available for each input).
Seems that what you try to do in the end is to run your operation in dry-run mode.
My suggestion would be to add a dry-run option as request parameter for instance.
/employee/basic?dry-run=true
REST says that you should use standards like HTTP to achieve a uniform interface. There are no URL standards as far as I know, even OData says that its URL naming conventions are optional.
Another thing that the browser is a bad REST client. REST was designed for webservices and machine to machine communication, not for the communication of browsers with webapplications, which is sort of human to machine communication. It is for solving problems like automatically order from the wholesaler to fill my webshop with new items, etc. If you check in this scenario both the REST service and REST client are on servers and have nothing to do with the browser. If you want to use REST from the browser, then it might be better to use a javascript based REST client. So using the browser with HTML forms as a REST client is something extreme.
If you have a multitab form, then it is usually collected into a session in regular webapplications until it is finalized. So one solution is having a regular webapplication, which is what you actually have, since I am pretty sure you have no idea about the mandatory REST constraints described by Fielding. In this case you just do it as you want to and forget about REST.
As of naming something that does validation I would do something like POST /employee/basic/validation and return the validation result along with 200 ok. Though most validation rules like "is it a date", "is it a number", etc. can be done on the clients currently they can be done even in HTML. You can collect the input in a session on server or client side and save it in the database after finilazing the employee description.
As of the REST way I would have a hyperlink that describes all the parameters along with their validations and let the REST client make tabs and do the REST. At the end the only time it would communicate with the REST service is when the actual POST is sent. The REST client can be in browser and collect the input into a variable or cookies or localstorage with javascript, or the REST client can be on server and collect the input into a server side session for example. As of the REST service the communication with it must be stateless, so it cannot maintain server side session, only JWT for example where all the session data is sent with every request.
If you want to save each tab in the webservice before finalizing, then your problem is something like the on that is solved with the builder design pattern in programming. In that case I would do something like POST /employeeRegistrationBuilder at the first step, and which would return a new resource something like /employeeRegistrationBuilder/1. After that I can do something like PUT/POST /employeeRegistrationBuilder/1/basics, PUT/POST /employeeRegistrationBuilder/1/education, PUT/POST /employeeRegistrationBuilder/1/workExperience, etc. and finalize it with PUT/POST /employeeRegistrationBuilder/1/finished. Though you can spare the first and the last steps and create the resource with the basics and finish it automagically after the workExperience is sent. Cancelling it would be DELETE /employeeRegistrationBuilder/1, modifying previous tabs would be PUT/PATCH /employeeRegistrationBuilder/1/basics. Removing previous tabs would be DELETE /employeeRegistrationBuilder/1/basics.
A more general approach is having a sort of transaction builder and do something like this:
POST /transactions/ {type:"multistep", method: "POST", id: "/employee/"}
-> {id: "/transactions/1", links: [...]}
PATCH /transactions/1 {append: "basics", ...}
PATCH /transactions/1 {append: "education", ...}
PATCH /transactions/1 {remove: "basics", ...}
PATCH /transactions/1 {append: "workExperience", ...}
PATCH /transactions/1 {append: "basics", ...}
...
POST /employee/ {type: "transaction", id: "/transactions/1"}
-> /employee/123
With this approach you can create a new employee both in multiple steps or in a single step depending on whether you send actual input data or a transaction reference with POST /employee.
From data protection (GDPR) perspective the transaction can be the preparation of a contract, committing the transaction can be signing the contract.
I am trying to retrieve a list of projects from the OpenStack API, and would like to use pagination in order to retrieve n projects at a time.
In the OpenStack documentation, it states that I can append "/?limit=n" to the URL and up to n results will be fetched accordingly.
However, when executing the GET request to the URL as follows:
https://identity-3.eu-de-1.cloud.sap/v3/auth/projects/?limit=1
I still get ALL projects. I can't seem to understand what I am missing.
NOTE: the request itself works and returns results as needed, but simply ignores the limit parameter (this is not an authentication issue).
I think it does not all OpenStack API provide limit parameter
In keystone API doc, there is no limit parameter in Request parameter descriptions for /v3/auth/projects API
keystone-project-API-doc
Other services like cinder volume list, it provides limit parameter in doc
cinder-volume-API-doc
Front end: HTML
Backend: Java servlet
I have to get data from database to vue.js to show in an HTML tag without the servlet's help. How can I get that data?
The task is a todo list. When I click on a specific button, text is stored to a database. After that, I have to display all the content that is stored in the database. This means all the data of the todo list should be displayed without the help of a select query from the servlet. How is this possible?
You have to run your servlet eg http://localhost:8888
Create API in your servlet like: POST /api/tasks/ for creation, GET /api/tasks/ to get all tasks etc. I am not Java programmer so I am using general conventions as making API is similar in all languages. If you don't know how - use Google to find something like 'Creating API in Java'
Add eg. Axios to your Vue application.
Consume your API with axios like
Vue.axios.get('http://localhost:8888/api/tasks').then((res)=>{
//server response data is available in res.data
// do whatever your want with your data
})
Hope it helps.
I have a jsp file pageshow.jsp and the parameter id,
Is there any way to cache the jsp file in server-side based on the url parameter
Requesting page pageshow.jsp?id=100 get from cache instead of building from server
Requesting page pageshow.jsp?id=200 get from cache instead of building from server
Above two pages should have different cache content since their parameter are different
This may avoid the rebuilding the jsp file in server side and also decrease the server load
I'd take a look at using a CachingHttpFilter similar to what AlexR has proposed, but look at using the HTTP headers to control the caching rather than storing data in a roll-your-own-content-cache.
This article explains nicely how to go about comparing the If-Modified-Since HTTP header when a URL is requested subsequent times. It's then up to your Filter to send back a HTTP 304 response.
Comparison of dates:
The client asks the server to a specific page: if the client has
already read the page, it sends a request (to server) containing the
last modification date of its cached page (eg “If-Modified-Since:
21/07/2002 13:47:24 GMT”);There also the header If-Unmodified-Since;
The server compares this date given by the client with the last
modified date of requested page:
if the page on the server has the same date, then the server informs
the client that it can use the version’s page in its cache (“HTTP/1.1
304 Not Modified”). The exchange between client and server stops
there;
if the page on the server is newer, then the server informs the client
of the change (“Last-modified: 21/06/2012 08:45:37 p.m. GMT”) and sent
this page to client. The browser stores the date of last change of the
page.
You will also want to look at the ETag HTTP Header.
Unfortunately caching sounds simple but is often difficult to get right. Tuning your database queries is often the best place to start with improving your application performance.
You can create CachingHttpFilter that is mapped to this JSP page only and does the following:
checks whether cached content exists
if exists just returns it
if does not exist calls chain.doFilter(request, response); that will go to the requested JSP. But passes there special response (response wrapper) that stores all bytes returned by the JSP and caches them.
I've got two pages in two different projects (it means in different ear files that are deployed singularly) and i need to pass data from a page to another.
in the action of a command link i do
public String onSalva() {
ADFContext.getCurrent().getApplicationScope().put("comingFrom", md);
return "goToPrint";
}
and in the constructor method of the backing bean of the other page i do:
page = (String)ADFContext.getCurrent().getApplicationScope().get("comingFrom");
But page is always null. I tried using process, session and request scop with no luck. Is there a way i could redirect to the other page by specifying manually the parametrs?
Something like
return "goToPrint?pageFrom="+md;
}
When you say "different EAR", then that means the two applications are isolated from each other and there is no simple way to get data from one to the other via Java.
Instead, you have to use the HTTP protocol. If you just want to go to a URL, use HttpServletResponse.sendRedirect()
This will open the new page in the browser as if the user had typed the URL into the location bar. The browser will no longer talk to your first application
If you want to stay in your first application and just send some data to the other side, there are several ways: You could embed the other app with an iframe - That would not allow you to exchange data but the user could fill and submit a form, for example.
Or you could use a library like HttpClient to talk to the other application. This would allow you send POST requests and do everything a web browser could do with the other app.
Lastly, you could define a shared enterprise bean which both EARs consume. One approach would be to define a message service to which boths apps subscribe. The first one creates the messages and puts them into the queue and the second one waits for the message and does something with it.