I currently have a grails project running in tomcat that acts as a container for a bunch of various information. I would like to build a client app (using java) that is capable of querying the grails project for particular information, based on parameters passed to it. I'm curious as to the best approach for something like this. My first inclination is to build the client in such a way that it just directly querys the DB on the back end of the grails project (the grails project will then just be used as an entry/modification method for the data). I was wondering if there is a better approach, maybe building a particular URI and then sending a GET request to the URI (this seems like a better approach as you only have one entry point then and you are not mucking directly with the DB). Just looking for some input from anyone who has worked on anything similar. Thanks in advance.
The first thing that comes to mind is "web service". What you describe as a "better approach" is actually part of the definition of a RESTful web service.
There are a couple of arguments against your "client queries DB directly" right off the bat.
One is scalability. If you have only one client, it won't make much of a difference. But when you have multiple clients, then each client will have to know intimate details about your DB. When something changes on your DB design, you have that many potential clients that need to be changed. As the scale of usage becomes bigger, so does this problem. This is what we call a solution that does not scale well. What you want to do is define an API, such as that provided by a web service. The API defines a stable contract that clients can depend upon your application to honor. The API hides implementation details and helps insulate clients from changes: as long as the API contract is honored, clients are oblivious to any implementation changes.
Another issue with the "client queries DB" approach is security. By exposing intimate knowledge of your database to client programs, you increase your surface of exposure for potential attack. An API provides an abstract facade that hides those intimate details and makes attacking your DB more difficult.
If you do go with the DB connection approach, you can avoid some of the problems Junilu mentions by providing an application layer in the database. So provide views and/or stored functions to access the data, and give clients permission to access these but not the underlying tables. This layer now becomes your public API. That way you can release precisely the information you need, and hide the implementation details. You'd also be able to make some changes to the underlying tables without affecting the clients.
Web services would give you even more flexibility, but this is alternative if you don't choose that approach.