3

In REST Web Services we have GET AND DELETE methods.

Generally we read GET is to get data from server like "getCountriesName" and DELETE is used to call resource which deletes particular object like "removeOrganization".

But if i implements DELETE to "getCountriesName" then it successfully returns country name.

So how both are different? Any real-time scenario?

Alexandru Marculescu
  • 5,569
  • 6
  • 34
  • 50
fatherazrael
  • 5,511
  • 16
  • 71
  • 155
  • It seems like a poor implementation more than anything. Technically it is possible, but it would be very confusing, that is the reason why "constraints" exists. – vtortola Oct 28 '16 at 14:09

4 Answers4

3

It is technically possible, but if you make that way, then you are not following the REST standards. I would recommend to use delete to remove resources and get to query them

jgou
  • 93
  • 5
  • 1
    So it is about following standards only. This makes only difference? Technically using any of them is same? – fatherazrael Oct 28 '16 at 09:04
  • 1
    Yes. It is technically the same. However, if you use the standards, everybody will know how to call your API without checking any documentation. So, it is useful in case of exposing an API – jgou Oct 28 '16 at 09:45
2

Looking at the Richardson Maturity Model, if you're aiming to achieve at least level 2 of REST, you'll end up with resources (Country) and HTTP VERBS:

GET /api/countries/{id}

which would also return the country's name, among other parameters. You could also issue a DELETE request towards the same URL, provided there's an endpoint that supports this - in the backend you'll usually have methods that allow a certain HTTP VERB on them. The details of the implementation depend on the language you're using, for example in C# you would have a method with mostly the same signature, but a different attribute on top of it, like [HttpDelete]).

Thinking in terms of methods (getCountriesName/removeOrganization) is not RESTful at all, but rather SOAP/RPC.

Alexandru Marculescu
  • 5,569
  • 6
  • 34
  • 50
  • That two are just examples but question is how DELETE is different from GET? If implementation is same for both? – fatherazrael Oct 28 '16 at 07:07
  • If implementation is the same for both there must be some sort of mistake; in the `GET` method you'll usually retrieve the object/resource through the provided ID, while in the `DELETE` method you might do the same at the beginning, but then delete it from the DB/soft delete it (update some sort of status) – Alexandru Marculescu Oct 28 '16 at 07:10
1

How your service handles requests is completely up to you. You could basically create new resources on receiving GET requests or delete things using OPTION, though I highly recommend to not do so as this does not adhere to the backing protocol (HTTP in this specific case) and thus violates a basic REST constraints. Note further that a RESTful service should always adhere to and respect the supported protocols.

According to RFC 7231, one of the major differences between GET and DELETE is, that the latter one removes an association from a given resource and its functionality and also that the returned response is not cachable. This may or may not remove the data physically, the effect on consecutive DELETE or GET operations is, however, that the deleted resource should not be obtainable further. A consecutive DELETE request is issued to the server regardless of any previous request. If the resource was deleted before, the service should notify the client with a propper 404 Not Found error response if no new resource was created in between two delete operations on the same resource.

GET responses, on the other side, are cachable and thus may save work on the server by returning the result from a previous request directly from the (proxied) cache rather then issuing the request to the server. This can be fine-grained with propper cache-header settings.

Community
  • 1
  • 1
Roman Vottner
  • 12,213
  • 5
  • 46
  • 63
0

The type of HTTP method to be used is more of a convention and a practice to be followed. This would give wrong information when the API s are exposed to the external systems

Refer to the blog post for detailed info