Category Archives: HTML

tooltip using css and html (balloon)

css

html

idempotent for PUT vs POST

http://stackoverflow.com/questions/630453/put-vs-post-in-rest?rq=1

Better is to choose between PUT and POST based on idempotence of the action.

PUT implies putting a resource – completely replacing whatever is available at the given URL with a different thing. By definition, a PUT is idempotent. Do it as many times as you like, and the result is the same.

x = 5 is idempotent. You can PUT a resource whether it previously exists, or not (eg, to Create, or to Update)!

POST updates a resource, adds a subsidiary resource, or causes a change. A POST is not idempotent, in the way that x++ is not idempotent.

By this argument, PUT is for creating when you know the URL of the thing you will create. POST can be used to create when you know the URL of the “factory” or manager for the category of things you want to create.

so:

POST /expense-report
or:

PUT /expense-report/10929

Sending file from html to node server (multer)

node server download

ref – https://dzone.com/articles/upload-files-or-images-to-server-using-nodejs

client side

Server side – index.js

Make sure you create the folder Images at the the directory your index.js is at.

However, our solution always jumps to another page.
In order to do it without any jump, we do it without a form

non-form way

First, we create a file uploader, and button control

For the button, whenever we press it, we will run function uploadImage
In this function, we first get the file object via the files property. The files property is an array, and we simply get the first element.

Once we have this file, we create a FormData object, append our file to it. Make sure to call it “imgUploader” as that’s what our multer code from the server side is expecting.

Assign the form data object to body and that’s it.

GET vs POST

GET – Requests data from a specified resource

Note that the query string (name/value pairs) is sent in the URL of a GET request:
/test/someURL?name1=value1&name2=value2

Some other notes on GET requests:

  • GET requests can be cached. As in the URL with the query string will be cached in your browser.
  • GET requests remain in the browser history
  • GET requests can be bookmarked
  • GET requests should never be used when dealing with sensitive data, because the data is displayed in the URL via the query string
  • GET requests have length restrictions. As of 7/2015, most webservers have a limit of 8192 bytes (8KB), which is usually configureable somewhere in the server configuration.
  • GET requests should be used only to retrieve data

A GET should not have a body, so aside from cookies, the only place to pass info is in the URL.

POST – Submits data to be processed to a specified resource

The POST Method

Note that the query string (name/value pairs) is sent in the HTTP message body of a POST request:
POST /test/demo_form.asp HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2

Some other notes on POST requests:

  • POST requests are never cached
  • POST requests do not remain in the browser history
  • POST requests cannot be bookmarked
  • POST requests have no restrictions on data length

Besides keeping the URL relatively cleaner, POST also lets you send much more information (as URLs are limited in length, for all practical purposes), and lets you send just about any type of data (file upload forms, for example, can’t use GET — they have to use POST plus a special content type/encoding).

POST vs PUT

ref – http://stackoverflow.com/questions/630453/put-vs-post-in-rest

Overall:

Both PUT and POST can be used for creating.

You have to ask “what are you performing the action to?” to distinguish what you should be using. Let’s assume you’re designing an API for asking questions. If you want to use POST then you would do that to a list of questions. If you want to use PUT then you would do that to a particular question.

Great both can be used, so which one should I use in my RESTful design:

You do not need to support both PUT and POST.

Which is used is left up to you. But just remember to use the right one depending on what object you are referencing in the request.

Some considerations:

Do you name your URL objects you create explicitly, or let the server decide? If you name them then use PUT. If you let the server decide then use POST.

For example, notice that your URL object you name the user_email explicitly to modify/create. Thus you use PUT.

Notice we let the server make decisions when we create the user. Hence we use POST

PUT is idempotent, so if you PUT an object twice, it has no effect. This is a nice property, so I would use PUT when possible.

note: idempotent means whenever it is applied twice to any value, it gives the same result as if it were applied once.

You can update or create a resource with PUT with the same object URL.
But with POST you can have 2 requests coming in at the same time making modifications to a URL, and they may update different parts of the object.

POST:

Used to modify and update a resource

POST /questions/ HTTP/1.1
Host: wahteverblahblah.com

Note that the following is an error:

POST /questions/ HTTP/1.1
Host: wahteverblahblah.com

If the URL is not yet created, you should not be using POST to create it while specifying the name. This should result in a ‘resource not found’ error because does not exist yet. You should PUT the resource on the server first.

You could though do something like this to create a resources using POST:

POST /questions HTTP/1.1
Host: wahteverblahblah.com

Note that in this case the resource name is not specified, the new objects URL path would be returned to you.

PUT:

Used to create a resource, or overwrite it. While you specify the resources new URL.

For a new resource:

PUT /questions/ HTTP/1.1
Host: wahteverblahblah.com

To overwrite an existing resource:

PUT /questions/ HTTP/1.1
Host: wahteverblahblah.com


I think one cannot stress enough the fact that PUT is idempotent: if the network is botched and the client is not sure whether his request made it through, it can just send it a second (or 100th) time, and it is guaranteed by the HTTP spec that this has exactly the same effect as sending once.

sample

“article” is related to “section”, but is distinctly different. Whereas

is for grouping distinct sections of content or functionality,

is for containing related individual standalone pieces of content, such as individual blog posts, videos, images or news items. Think of it this way – if you have a number of items of content, each of which would be suitable for reading on their own, and would make sense to syndicate as separate items in an RSS feed, then “article” is suitable for marking them up.

In our example,

contains blog entries. Each blog entry would be suitable for syndicating as an item in an RSS feed, and would make sense when read on its own, out of context, therefore “article” is perfect for them:

like so:

html5_layout

In short, a header typically contains at least (but not restricted to) one heading tag (h1 – h6).

Figure and figcaption

Articles

An easy smell test is would this make sense in an RSS feed? Of course weblog articles and static pages would make sense in a feed reader,

  • Break mechanical cab driver.
  • Drive to abandoned factory
  • Watch video of self



some copyright print for this site heheheh