The Rest is Silence... Not yet? Mapping CRUD methods to HTTP methods...

The Rest is Silence...

Not yet? Mapping CRUD methods to HTTP methods for RESTful Services

The most useful HTTP methods are four methods: POST, GET, PUT, and DELETE.
These correspond to create, read, update, and delete (generally speaking CRUD) operations.
We can also use OPTIONS and HEAD sometimes as HTTP methods...

Recommended return values (http://www.restapitutorial.com/httpstatuscodes.html)
of four most useful REST HTTP methods are as follows:

With an entire Collection (e.g. /products):
HTTP Method/Verb   
    GET     200 (OK), list of products. Use pagination, sorting and filtering to navigate big lists.   
    PUT     404 (Not Found), unless you want to update/replace every resource in the entire collection.   
    POST     201 (Created), 'Location' header with link to /products/{id} containing new ID.   
    DELETE     404 (Not Found), unless you want to delete the whole collection—not often desirable.   
      
With a specific Item (e.g. /products/{id}):
HTTP Method/Verb
    GET     200 (OK), single product. 404 (Not Found), if ID not found or invalid.
    PUT     200 (OK) or 204 (No Content). 404 (Not Found), if ID not found or invalid.
    POST     404 (Not Found).
    DELETE     200 (OK). 404 (Not Found), if ID not found or invalid.

Summarizing up:
Create  --> POST to a base URI returning a newly created URI
            PUT with a new URI
Read    -->  GET
Update  -->  PUT with an existing URI
Delete  -->  DELETE
  
GET (along with HEAD) requests are used only to read data and not change it.
Do not expose unsafe operations via GET. It should never modify any resources on the server.

PUT is not a safe operation, in that it modifies (or creates) state on the server, but it is idempotent.
In other words, if you create or update a resource using PUT and then make that same call again,
the resource is still there and still has the same state as it did with the first call.

It is recommended to keep PUT requests idempotent.
It is strongly recommended to use POST for non-idempotent requests.

The POST verb is most-often utilized for creation of new resources.
POST is neither safe nor idempotent.
It is therefore recommended for non-idempotent resource requests.
Making two identical POST requests will most-likely result in two resources containing the same information.

DELETE is pretty easy to understand. It is used to delete a resource identified by a URI.

There is a caveat about DELETE idempotence, however.
Calling DELETE on a resource a second time will often return a 404 (NOT FOUND) since
it was already removed and therefore is no longer findable.

Using GROUP BY with HAVING and aggregation function

Using GROUP BY with HAVING and aggregation function

Suppose that we need use SQL sentence to sum up the prices of invoices grouping by Product,
and display the result under condition that sum is less than 777.

We can use general SQL HAVING Syntax:

SELECT column_name, aggregate_function(column_name)
FROM table_name
WHERE column_name operator value
GROUP BY column_name
HAVING aggregate_function(column_name) operator value;

Then I can use the following SQL statement:

SELECT Product, SUM(InvoicePrice)
FROM Invoices
GROUP BY Product
HAVING SUM(InvoicePrice) < 777;

Republic of Garbage Collections

Republic of Garbage Collections
...and rules of life of GC Citizens:

package com.jeeprojectsnippets.gc.eligible;

public class Eligible {

      

       int j;

       public static void main(String[] args) {

             Eligible first = new Eligible(11);      // 11

             Eligible second = new Eligible(12);     // 12

             Eligible third = new Eligible(13);      // 13

             Eligible fourth = new Eligible(14);     // 14

             fourth = first.run(third); // fourth is set to null and marked for GC

             second = null; // second and fourth have been set to null and marked for GC

             tryTest("First: ", first);

             tryTest("Second: ", second);

             tryTest("Third: ", third);

             tryTest("Fourth: ", fourth);

            

             System.gc();

            

             tryTest("First: ", first);

             tryTest("Second: ", second);

             tryTest("Third: ", third);

             tryTest("Fourth: ", fourth);

       }

       public Eligible(int j) {

             this.j = j;

       }

       private Eligible run(Eligible eligible) {

             eligible = null;    // third is not set to null - this copy of 

                                 // eligible reference exists!

             return eligible;    // null is returned

       }

       public String toString() {

             return "" + j;

       }

       public static void tryTest(String msg, Eligible eligible) {

             try {

                    System.out.print(msg);

                    System.out.println(eligible);

             } catch (Exception e) {

                    System.out.print(msg);

                    System.out.println((String) null);

             }

       }

}

And the output of the test is:

First: 11

Second: null

Third: 13

Fourth: null

First: 11

Second: null

Third: 13

Fourth: null

An object becomes eligible for garbage collection in Java in following situations:

a. If an object has only live references via WeakHashMap

b. Parent object is set to null

c. All references of that object explicitly are set to null e.g. obj = null

d. Object is created inside a block/loop and reference is out of scope.

Java objects are created in Heap, and we can say about Heap Generations.

Heap is divided into 3 generations for sake of garbage collection in Java:

1. Young generation,

2. Tenured or Old Generation,

3. and Perm Area of Heap.

New objects are created into young generation and subsequently moved to old generation.

Young/New Generation is further divided into 3 parts known as:

1.1.  Eden space,

1.2.  Survivor 1 space

1.3.  and Survivor 2 space.

Perm Area of Heap (Permanent generation) is somewhat special and it is used to store Meta data related to classes and method in JVM. It also hosts String pool provided by JVM. That can explain why String is immutable in Java.

We can use methods like System.gc () and Runtime.gc () which is used to send request of Garbage collection to JVM, but it is not guaranteed that garbage collection will happen at all.

The garbage collection thread invokes finalize() method before removing an object from memory of the object and gives us an opportunity to perform any sort of cleanup required.

Garbage collection tuning generally depends on fact what kind of object application has and what are there average lifetime etc.

Read more:

  http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html

  http://javarevisited.blogspot.com/2011/04/garbage-collection-in-java.html