I am currently new to RESTful Architecture and using Jersey to practice. i am facing difficulty in implementing GET operation.following REST naming/URL convention for getting a particular customer from the server would be
GET http://www.example.com/customers/33245
However while designing client side how would the client know that specific id belong that specific customer as it would be in the database linked with the server and hidden from client. One implementation i think of is to extract all the information regarding all the customers from the database and store in the client but i believe it kills the whole purpose. what should be the optimum way for searching for a specific customer.
Such an URL is used for getting a customer that you already know. Not for searching customers.
For searching customers, you would typically use an URL like
http://www.example.com/customers?name=Doe&firstname=John
This would list all the customers named John Doe, and the list would contain, for every customer, the ID of the found customer. The client would then use this ID to invoke the URL in your question and get detailed information about this customer.
You can of course use any query criteria you want, or allow accessing customers by other means.
If you think about it, that's exactly how web searchingworks. You don't know the URL of a page, you search for this page by keywords on Google, which returns a list of results containing the title, description and URL of thepage, then you use the URL to actually access the page.
Related
I have a Java XPages application with a REST service that functions as an API for rooms & resources database (getting appointments for specific room, creating etc).
The basic workflow is that an HTTP request is being made to a specific REST action, having the room's mail address in the search query. Then in the java code I'm iterating over all documents from the rooms & resources database, until I find a document with the InternetAddress field with the searched mail address.
This isn't as fast as I would like it to be, and there are multiple queries like this being made all the time.
I'd like to do some sort of caching in my application, that when one room is found once, it's document UID is being stored in a server-wide cache so next time a request is made for this mail address, I can directly go to the document using getDocumentByUNID(), which I think should be way faster than searching over the entire database.
Is it possible to have such persistent lookup table in Java XPages without having any additional applications, while keeping it as fast as possible? A hash table would be perfect for this.
To clarify: I don't want caching in a single request, because I'm not doing more than one database lookups in a single query, I'd want to keep the caching server-wide, so it would be kept between multiple requests.
Yes, it is possible to store persistent data. What you are looking for is called an application scoped managed bean.
I need to build a /search API that allows someone to send a POST, and retrieve an ID that can be queried later via a seperate /results API.
I've looked at Spring methods:
DeferredResult
#Async
but neither seem to demonstrate returning an ID from a search. I need to have a system that can remember the ID and reference it when someone calls the /results API to retrieve specific results for a search.
Are there any examples of a Spring application doing this
You must remember that Restful services are stateless, therefore It won't be a good practice keeping your search results states in the server.
One solution could be storing your search states on a Database (SQL/NoSQL) and using the Spring Cache support to improve response times.
When an user requests a new search using /search, on the server you must generate the ID, prepare your results and persist it on the database, then you send the new ID to the client. Later the client must request its results using /results/{searchId}.
Please let me know if you'll use this possible solution and I'll share you an example on Github
I'm building a web service to support an Android e-reader app I'm making for our campus magazine. The service needs to return issue objects to the app, each of which has a cover image and a collection of articles to be displayed. I'd like some general input on two strategies I'm considering, and/or some specific help on a few issues I'm having with them:
Strategy 1: Have 2 DB tables, Issues and Articles: The Issues table contains simply an int id, varchar name and varchar imageURI. Articles contains many more columns (headline, content, blurb, etc.), with each article on a separate row. One of the columns is issueID, which points to the issue to which the article belongs. When issue number n is requested, the service first pulls its data from the Issues table and uses it to create a new Issue object. The constructor instantiates a new List<Article> as an instance variable and populates it by pulling all articles with the matching issueID from the Articles table. What I can't figure out with this option is exactly how to execute it at a single endpoint, so that app only has to create one HTTP connection to get everything it needs for the issue (or is this not as important as I think it is?).
Have a single Issues table with the id, name, and imageURI columns, plus a large number of additional text Article1... text Article40 columns. The Articles are packaged into JSONObjects before being uploaded to the server, and these JSONObjects (which will be very long) are stored directly in the database. My worry here is that the text files will be too long, plus I have a nagging suspicion that this strategy isn't in line with best practices (although I can't put my finger on why...)
Also, This being my first web service, and given the requirements specified above, would it be advisable to use the Spring (or some other) framework or am I better off just using JAX-RS?
There are 2 questions here
How to convert your objects to JSON and expose them with a rest service.
How to store/retrieve your data.
To implement your webservices, Jersey is my favorite option. It is the open-source reference implementation of the JSR 311 (JAX-RS). In addition, Jersey uses Jackson to automatically handle the JSON/Object mapping.
To store your data, your second option... is clearly not an option :)
The first solution seems viable.
IMHO, as your application seems tiny, you should not put in place JPA/Hibernate etc.You should simply make one request by hand with a JOIN between Issues and Article, populate the requested Issue then let Jackson automatically convert your object to JSON.
I am to the topic of Hibernate. I am working no on validation system now. I would like to search the database, whether data entered by the user already exists in it, such as login. How to do it using hibernate?
Please check following link: http://gwt-vl.sourceforge.net/?to=serverDoc
Esspecially the section: Server side to client side validation This may help you to validate your form on the server side.
If you need to know about communication with backend I would recommend (GWT_PLATFORM)[http://code.google.com/p/gwt-platform/] it's a great framework by Philip Beaudoin and also some highly respected by GWT team and was infect release before GWT MVP . Okay you already have that sorted out then what you will need to work out what combination of UI fields is a unique database entity for example Name and Date of Birth something along these lines. Then before you persist this data you will using your DAO (I am assuming you have a DAO layer) search for that object (you can use JPA QL even with hibernate or Hibernate Criteria) if your search (and user doesnot know about it just a back end process) does not return a result then you can just persist then new information but if it does then it will be upto the business rule weather you show user and error or update the information.
Still learning JSP Web Applications here.
I have been doing this for a while in my web application but I would like to know a more secured solution.
Imagine a Table that displays certain Book Information. When user clicks one of the rows in the table,
I basically send the BookID together with the url.
Example URL. http://locathost:8080/myapp/editbook.htm?bookID=3
in my servlet.
String strBookID = request.getParameter("bookID");
I think this is a little weak, is there a way where I could provide a more secure way other than this.
Its quite easier for hacker to edit the URL if I send the BookID together with the URL.
Can you share me some link on how to do this in both the Client Side and Server Side?
Thanks
I think this is a little weak, is there a way where I could provide a more secure way other than this.
You have to define "secure" on the basis of your application. The requirements are totally different for a public website selling books v/s a private library hosting confidential volumes v/s anything other application in between.
At a minimum, you should do the following -
Verify that bookID is in fact an Integer and is within an expected range.
Ensure that you bind bookid in a parameterized SQL Query - this is to prevent SQL Injection.
Show a 'Book not found' page if the book cannot be found
For a public website, the above is enough. You actually want people to discover your books, so if someone modifies the bookID, you shouldn't care.
For a secure library, you have to do a lot more.
Ensure that the URL is protected in web.xml, so only authenticated and authorized users can get to the URL
Verify the current user has access to the bookID. You can store the list of books available to a user in the session object.
If the user does not have access, return a 403 error page.
There are several other strategies to protect URLs; some use tokens to ensure the URL hasn't been manipulated. Others don't send bookID to the client, and instead rely on number {1 through n} where only the server knows that 1 corresponds to Book A and so on. But the idea is to ensure that a user doesn't get access to a book he doesn't have permissions to.
If you are using Spring, I'd highly recommend Spring Security. Otherwise look into JAAS.
You have to suppose that any user can send anything to you. The solution isn't avoiding users to send data in URL, it's to control that they can in fact do the following operation.
You need authentication and authorizations.
How to use authentication with your web.xml
Defining Security Requirements for Web Applications