All geek questions in one place

Is my web service RESTFUL?

I have a REST web service that provides 2 methods -

  • [POST method] The client will provide a list of objects in XML form. My web service method inserts / updates the list of objects based on a single attribute in the object [mode = insert / update] and returns XML with a list of objects and their status [whether the insert / update was successful].
  • [POST method] It will take a list of objects and return the status of these objects from the server as XML.

I know we should use

  • GET method for extracting information
  • POST method to create a new entry
  • The PUT method to update an existing record.

I know that our implementation violates some of the limitations of REST, but our requirement has forced us to implement it this way.

My question is: is it good to bend the constraints to satisfy our requirement?

+4
source share
3 answers

What you are trying to do can be done RESTfully. Although POST is typically used to add a single object to a collection, it can also be used to send a piece of data to a "data processing resource." This pretty much opens the door to do whatever you want with POST.

People often misunderstand REST restrictions and believe that you SHOULD use PUT and DELETE in order to be RESTful. This is not the case. There is no requirement to use all methods. The only requirement is not to abuse the ones you use.

Obviously, this will be more intuitive for the user of your API if you add one object to the collection to create the object. However, if this is not suitable for you, you can define a new type of medium, which may contain a set of objects that will be created / updated by some data processing resource.

It is important that these rules be clearly indicated. You must create a new media type, for example application/vnd.yourcompany.objectlist+xml , and you need to write documentation about how this media type should be structured.

Now that you have determined the type of media, your client will need to know where POST is this list of objects. Ideally, you would define a new link relation (e.g. objectprocessor ) that could be used in other documents to provide a POST URL. In the specification document for this Link relationship, you must explain to the client developers that when you send application/vnd.yourcompany.objectlist+xml to a link that has a link objectprocessor relationship, then the following will happen: x, y and z.

Assuming your root URL returned some kind of XHTML document, for example:

 <html> <h1>My awesomely restful service that can create objects in batches</h1> <link rel='objectprocessor' href='http:/example.org/myservice/objectprocessor'/> </html>

The client application can process this document, detect this link and understand it based on the definition of the link relationship that is required for POST a application/vnd.yourcompany.objectlist+xml to the endpoint specified in href.

Thus, the message is completely self-descriptive, you interact with resources identified with URLs that can be found, and you are within the rules of a uniform interface.

+6
source

This web service is not RESTful. You can always bend restrictions, but you lose the REST label REST

+1
source

The problem with rule bending is that customers consuming your web services may accept things that may not apply. In general, this is not a big problem if you have a client and a service, but for a public web service, you might want to consider joining REST principles better.

+1
source

Source: https://habr.com/ru/post/1314176/

More articles:


All Articles