Http Methods - Idempotent - Categorization

I'm planning to use the following http methods and the respective operation

GET : Retrieve
POST : Create
PUT : Update/Replace
DELETE : Delete
GET: Download
POST: Upload

is the above approach is correct ?

Will there will be any issue with respect to Idempotent ???
Software ProgrammerAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

girionisCommented:
You can also use PUT for creation. GET, PUT and DELETE are idempotent. There is a good tutorial here that explains the differences:

http://www.restapitutorial.com/lessons/httpmethods.html

Will there will be any issue with respect to Idempotent ???

This depends entirely on you. When we talk about idempotency, we talk with regards to the resource representation and to the resource itself. It is possible that the resource representation is idempotent but the resource itself it is not. If, for example, you do a GET and in your endpoint you create a resource, then this is not real idempotency. You should design your application in that way that it is both idempotent and safe.
0
Software ProgrammerAuthor Commented:
I already read about it and not clear on the same. Basically i still don't understand the difference in the result. Can u help me with a code snippet and example input and output?
0
girionisCommented:
Ok, imagine a GET operation (I am using the example from one of your other questions) that you call with book id of "10"

 
  @GetMapping
  public ResponseEntity<Book> getBook(@PathVariable String id) {
    Book book = books.get(id);
    if (book == null)
      return ResponseEntity.notFound().build();
 
   String id = generateId();
    Book book = new Book(id, title, authorName);
    bookRepository.save(book);

    return ResponseEntity.ok(book);
  }

Open in new window


In the example above the GET is idempotent with regards to the resource representation, you are guaranteed to always get back the book that is represented with the id of "10".

But with regards to the resources themselves GET is not idempotent since when you call it you create a new book each time.

So you have to be careful when you implement your web app, do not mix operations that do not belong to the specific verbs if you want to truly be idempotent.
0
Cloud Class® Course: Python 3 Fundamentals

This course will teach participants about installing and configuring Python, syntax, importing, statements, types, strings, booleans, files, lists, tuples, comprehensions, functions, and classes.

Software ProgrammerAuthor Commented:
May be an example for DELETE and PUT will be clear. The above GET example is still not clear
0
girionisCommented:
A DELETE example would be similar to the one I posted.

In the above example these three lines

   String id = generateId();
    Book book = new Book(id, title, authorName);
    bookRepository.save(book);

Open in new window


create a new resource. So the GET request returns you the book you asked for, but it also creates a new book. This is not idempotency since you change the resources.
0
Software ProgrammerAuthor Commented:
So ideally speaking GET should not save. PUT should be used for Update. POST should be used for CREATE. is that right ???

When we use PUT for Update. We should make sure that we need to handle the status code correctly. Because of idempotent. is that right??
0
girionisCommented:
So ideally speaking GET should not save.

Yes.

PUT should be used for Update. POST should be used for CREATE. is that right ???

Yes. But you could also use PUT for create.

When we use PUT for Update. We should make sure that we need to handle the status code correctly. Because of idempotent. is that right??

You need to handle the status code correctly, but not because of idempotency. The idempotency is not dependent on the status code.
0
Software ProgrammerAuthor Commented:
The idempotency is not dependent on the status code is the meaning which i couldn't understand still. I understand the status code will differ when we try to do the same operation more than once...

Can you pleas point to a good article or a PPT or somelink which i can read in detail?
0
girionisCommented:
The idempotency is not dependent on the status code is the meaning which i couldn't understand still

I mean that the status code might change, but the operation can still be idempotent.

Imagine that you issue two DELETE operations. One returns 204 and the other returns 404. The status codes are different but the operation is idempotent since the second operation has the same effect. After the execution of both operations the resource is not on the disk.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Java

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.