0

I am creating a rest service that will match the inputs to find a resource. If the resource is found, it will return the resource otherwise it will create a new resource and will return that. As the call might change the server state (in case a new resource is created), this can not be GET call and should be a POST call. But there will be scenarios when the resource is found and no change is made to the server state.

What is the best way to expose this API. The options that come to my mind are:

Option 1: Expose single api as a POST api call.

Option 2: Expose 1 api for GET and another api for POST. The client will call GET and in case a resource is not found then make another call to create the resource.

I am leaning towards option 1 as I do not want the consumers to deal with the complexity of the operation and Option 2 will also have more latency owing to 2 trips to the server.

Please suggest any other pros/cons that I should consider for this design or if there are any other options.

pawinder gupta
  • 1,225
  • 16
  • 35
  • see https://stackoverflow.com/questions/18976050/restful-way-of-getting-a-resource-but-creating-it-if-it-doesnt-exist-yet for a possible duplicate – Scary Wombat Sep 28 '17 at 02:11
  • 2
    a single GET please. And the request should be authenticated or secured first. – Tiina Sep 28 '17 at 02:26
  • @Tiina *HTTP GET should be used for all retrieval. It should never be used to create, update, or do things.* see https://www.infoworld.com/article/3204125/apis/the-rules-for-rest-how-to-be-restful-in-httpjson-apis.html – Scary Wombat Sep 28 '17 at 02:29
  • 2
    @ScaryWombat I would argue that the resource from the caller's perspective was previously in an unknown state. In the problem statement they don't care whether it's a creation or a retrieval; they only care about retrieving the entity result. From the caller's perspective it should always be a GET invocation. To rephrase, the API should always be written from the viewpoint of the caller. – Craig Taylor Sep 28 '17 at 02:36
  • @CraigTaylor Of course, at the end of the day, the OP can do it however he wants, but it would not be following REST - not that I care. – Scary Wombat Sep 28 '17 at 02:39
  • 2
    @ScaryWombat Usually that is right, but the OP is doing `get on absent create`, it is meaningless a server exposes what its logic actually is when design its api. From the point of a client, it is getting. – Tiina Sep 28 '17 at 07:21
  • @ScaryWombat, that article is simply wrong. GET is absolutely the correct way to handle this. OP, your terminology is a little mixed up: if a URI is valid, such that GETting that URI returns a resource, then the resource "exists" in the RESTful sense. Whether the server uses previously cached data, or generates it on the fly, that's an implementation detail that really has nothing to do with REST. So, in the CRUD sense, you're implementing a "get or create" operation, but in the REST sense, it's just a GET. – John B Sep 28 '17 at 19:23

0 Answers0