0

I am trying to build a small REST API for one of our clients, who was wishing for that kind of API. It's the first time I read into that topic. Most of our services take quite some time for fully processing client orders. For that the client may create resources by POSTing xml data and retrieve results (much) later by GETting the corresponding resource. That was pretty straight forward.

Now though we want to create another service, which will typically evaluate results almost immediately and I really don't know, how to implement it with best practice. Since the request can be processed immediately I want to avoid using two requests for creating and retrieving the resource. It just seems unnecessary and laborious.

On the other hand one single fitting HTTP request method does not seem to exist for this problem since POST requests shouldn't respond with anything but a response-code and GET requests should be independent from their body (today it seems to be possible to send body data with GET requests, nevertheless it seems to be bad practice and should not influence the response. In other words the server is only allowed to use information, which is contained in the URL). Further I cannot send the data as query parameter in the GET-URL since the data contains very sensitive information - we have pretty strict laws regarding that topic in my country and I learned to be very careful .

What would be best practice for implementing such kind of responsive tool. Is the REST API maybe the wrong choice anyway?

Thanks

aphprentice
  • 11
  • You *can* use `GET`, if you use SSL as the query string will be encrypted (That isn't to say it won't appear in plain-text logs) – Stuart.Sklinar Sep 24 '21 at 15:26
  • Hi @Stuart.Sklinar, thanks. I guessed the URL itself may be in a TLS package when using https but I wasn't sure. But you are saying it should be completely safe when using https? – aphprentice Sep 27 '21 at 07:18
  • Why would anybody think the question was opinion-based? Explanation? – aphprentice Sep 27 '21 at 07:20
  • Completely safe "depends", I wouldn't advise it, but the query string is encrypted, what I meant was, once it reaches the server, there is nothing to stop that URL appearing in logs, with all the information of the query string in it. So it depends on your use case – Stuart.Sklinar Sep 28 '21 at 13:28

1 Answers1

1

POST requests shouldn't respond with anything but a response-code

This is not quite right.

In case of a POST that resulted in a creation, you should use a HTTP 201 status code and include a Location header that points to the URL of the new resource.

In addition, POST response may contain body with representation of the created object: 'Best' practice for restful POST response.

So the method POST is what you are looking for. It creates new resource and returns the representation of newly created object in the body.

If your service will modify objects after creation, it's up to you how to deal with it. If time of modification is very short, you can wait until object is modified and then return the object ready to use. Otherwise, you can return object with incomplete fields. Both approaches are RESTful.

Andrey Rodin
  • 133
  • 7
  • Thanks for your answer. I will try to implement that as well. – aphprentice Sep 27 '21 at 07:13
  • May I ask you smth corresponding about the creation of a resource? – aphprentice Oct 11 '21 at 13:03
  • I don't really understand which form the Location header takes in my personal application. In any example I found online the created resource is identified by a path pointing to its location. Now in my case the created resource is saved and edited in my db and a straight forward way to identify it were by the unique ID I assigned it. Since updating or editing in any form isn't intended in this app, the only sensible way seems to be sending the client the URL of a GET-Request à la restfulapi.com/app1/?id=12345. Did I miss smth? It doesn't seem right to respond with such Location Header. – aphprentice Oct 11 '21 at 13:19
  • You should return URL (relative or absolute) for GET-request. Here is pattern for POST method in .NET Core: ` var uri = Url.Link("GetDocumentById", new { id = result.Id }); return Created(uri, result);` – Andrey Rodin Oct 11 '21 at 20:20
  • Thank you very much. I don't have enough reputation for giving you +1, but feel appreciated :) – aphprentice Oct 13 '21 at 06:45
  • If the answer helped you, you can mark it as accepted. – Andrey Rodin Oct 13 '21 at 08:34
  • Well it did not answer the original question (or I still missunderstood) so that would be confusing for any future readers. – aphprentice Oct 14 '21 at 08:42
  • I will give it another try. Are you saying that after creating a resource the server should respond with a '201 created' and a location header containing the GET-Request which the client would need to call to retrieve the resources state? That would make totally sense. But! If the response is sent directly the resource obviously hasn't changed it state yet, since the processing ofc needs some time (microns). Is it legit to keep the response pending until the data is done processing to then respond with a location header, 'redirecting' the client to the information it desired in first place. – aphprentice Oct 14 '21 at 14:11