Java Reference
In-Depth Information
Again, take some time to explore this code at your own leisure. One “issue” that's still present is that
you are creating objects in an ad hoc manner, even if an object might already exist. For instance,
if you create two Invoice objects belonging to the same customer, the customer information is
requested twice, and two separate Customer objects are created containing the same information.
You might try to modify the code to work around this. To do so, you need a global set of object
“managing” classes, which keep track of a set of objects (customers, for instance). This class can then
provide a method—e.g., createOrGetCustomer —that returns a Customer object for a given ID if it
has been created earlier (stored in a map, for example) or fetches and creates a new Customer object
and returns that one (after adding it to its map for quick retrieval later). You can also try to add
constructors to the resource objects to create a resource by fetching information from a web service
(using the ObjectFactory ), instead of directly accessing the methods of ObjectFactory . You will
often have to think about these kinds of architectural decisions when writing more complex pro-
grams. Different solutions to solve the same problem exist, and depending on your needs, you might
need to add more abstraction or managing classes. As you get more experienced in programming in
Java, the right “patterns” to use for a given circumstance will present themselves more quickly and
easily, but don't be afraid to iterate over your code and refactor when necessary.
Note Another interesting aspect is the way to fetch “related” objects. For exam-
ple, when an Invoice object is created, the information for Customer is requested
immediately to construct a Customer object and store this in the Invoice object.
This technique is called “eager” loading, where you immediately request all infor-
mation you need, potentially leading to slower code. For instance, consider an
object with a very large related object. If you only need basic information, eagerly
loading the related object leads to bandwidth and time overhead.
As such, it would be possible to adapt your classes to only store the customer
ID for an invoice, for instance, and keep the Customer field set to null. Once
the programmer requests the full customer information (using the getCus-
tomer method), an additional request to the server to instantiate and set the
customer field can be fired. If you feel up for it, you can try modifying the code
to allow for “lazy” loading.
Note that the same terminology pops up when working with Object Relational
Mappers to interact with databases, for instance, to indicate whether you want
to immediately fetch all relations in a one-to-many connection or wait until the
programmer explicitly requests to do so.
In any case, now you know how to access a simple RESTful service using Java. Now, take a look
at a more complex RESTful service, which involves authentication and requests other than GET , in
order to send information to the service.
Accessing reSt Services with Authentication
Not all RESTful services are as simple as the one used in the previous section. In fact, many
RESTful services involve authentication of some kind.
 
Search WWH ::




Custom Search