Simple explanation of REST

A Bit About Basic REST


In REST, the basic idea is to expose the state of the system as a collection of individually addressable resources. You perform operations by manipulating these resources. A resource is an entity that has a state, as well as a name or id. Resources are stored in your backend—whether that is the Google Cloud Datastore, or something else.

As a general rule with REST, the client sees representations of the resources through requests made to the server. It can also update the resources by manipulating the representations, and sending the updated representations to the server via subsequent requests. Resources may be represented in a variety of ways: XML, JSON, CSV, or more. At this time, Cloud Endpoints only supports JSON, which tends to be less verbose and less vulnerable to human error than XML is.

You may have heard of CRUD (Create, Retrieve, Update, Delete), or variants of it. This is at the root of REST. When you use the Google Plugin for Eclipse to generate an Endpoint class, these types of basic methods are generated in the Endpoint class for you.

You are certainly not limited to those basic actions. Adding custom methods gives you much more flexibility, allowing you to perform complex operations. For example, checkForVictory might perform several queries, plus a write, to a database.

Martin fowler and Unity framework – Unity framework

Lectures on Data structures and Algorithms

Lectures on Data structures and Algorithms



CS courses


ORM – “Impedance mismatch”

Also known as “Paradigm mismatch”.

Object/Relational Mapping has an inherent paradigm mismatch when it comes to granularity,subtypes,navigating an object graph and polymorphism.

– The problem of granularity – Columns in a table are necessarily “scalar” (atomic). Perhaps there are database-specific features that dont have this limitation, but in general, this is a paradigm mismatch that must be kept in mind.

–  The problem of subtypes – How to map Inheritance hierarchies to database tables?

How to efficiently navigate an object graph? Example: userobj->getAddress()->getZip();

Interesting question: Why not use serialization for the persistence layer?

Java has a built-in persistence mechanism: Serialization provides the ability to write a graph of objects (the state of the application) to a byte-stream, which may then be persisted to a file or database. Serialization is also used by Java’s Remote Method Invocation (RMI) to achieve pass-by value semantics for complex objects.
Another usage of serialization is to replicate application state across nodes in a cluster of machines.

Why not use serialization for the persistence layer? Unfortunately, a serialized graph of interconnected objects can only be accessed as a whole; it’s impossible to retrieve any data from the stream without deserializing the entire stream. Thus, the resulting byte-stream must be considered unsuitable for arbitrary search or aggregation.
It isn’t even possible to access or update a single object or subgraph independently.
Loading and overwriting an entire object graph in each transaction is no option for systems designed to support high concurrency.

Hibernate is supposed to provide the most elegant solution to all the above mentioned problems.

Even better, Hibernate supports user-defined custom types. The interfaces UserType and CompositeUserType are provided to allow you to add your own types.


Guidelines from Bruce Eckel’s classic – Thinking in C++