REST or Representational state transfer

After worked on my project using REST frameworks, I realized my implementation of my project could be awkward if I relied heavily on HTTP GET method even though the stateless approach made good sense in the project.

Because of this awkwardness, I begin to look up problems with REST. One of the article I run into is 'RESTful APIs, the big lie'. Few things described in the article resonate with my development experience. After reading comments on the article, it is clear that there are quite few perception/understanding issues about the REST.

To get a bit of clarification I decided to see what Wikipedia have to say about the REST - sorry, I got practical projects to work on and have no intention of spending my time on theoretical debates.

Here's what I get out of the Wikipedia:
  The REST is largely what the Web is today (follow the constrains section) -
    Client-Server       - this is obvious.
    Statelessness
      - Except applications that using server side session storage.
      - Cookie is OK since it is client side
    Cacheability
      - Applications may not always specifically set it. But it is there.
    Layered system
      - HTTP fulfill it.
    Code on demand (optional)
      - basically, the javascript or others in the early days.
    Uniform interface
      Resource identification in requests
        - This call for identifying of resources which the URL basically fulfill it.
      Resource manipulation through representations
        - A working application not rely on server session will meet this constrains
      Self-descriptive messages
        - Wiki quote the example of media type - well, the implications are many
        - media type is just a code - that means all other info/code can be hard-coded.
        - I guess, we can stretch to say some message standard are to be specified.
      Hypermedia as the engine of application state
        - This is like to say a home/root page is desired
        - It serve as the root to discover all other resources.
  Applied to Web services
    As should be clear by now, the REST does not call for HTTP.

Most of today's so called RESTFul API/web-service are based on HTTP, but they don't have to. Also, based on HTTP does not make it RESTFul. Since HTTP is not called for, the use of GET/POST/PUT/DELETE should not be a criteria either - even if it is what most of people trying to do - now it make me wonder what role HTTP played in Roy Fielding's dissertation.

For me, I think I am happy with what I have after reading all these. From my assessment of my own project, I would say that what mine don't have at this point is the following:
  A home page that can reveal/lead to all resources.
  Message standard to be specified/published.
Other than that I think I am fine. Besides, I don't really want to reveal my message standard or provide a home page if I am not interested in making the API public. I may only reveal these to my business partners.