3

Right now I have a REST service which creates a report via a POST:

POST http://myhost/reports

The report however is not persisted, and cannot later on be retrieved via a GET:

GET http://myhost/reports/{id}

Instead I return the report immediately in the response to the POST. Am I violating any REST principle here, e.g. anything a POST creates should always be accessible via a GET, or is this setup OK?

per_jansson
  • 2,103
  • 4
  • 29
  • 46
  • Are you sure you cannot solve this with a GET request? – inf3rno May 22 '14 at 20:53
  • Are you referring to creating using a GET? I tried that first but thought it was incorrect to create something using a GET. But maybe it's OK. To any client it will then be about getting (and under the hood creating) the report for a specific customer, i.e: GET http://myhost/reports/{customerId} Would that make sense? – per_jansson May 22 '14 at 20:57
  • You are not creating something, because the result does not persist. You just ask the service to return a representation of existing resources... What should a report contain, and what resources do you have to support it? – inf3rno May 22 '14 at 21:00
  • Well, technically I'm creating a report based on current data for a specific customer. But I guess it can be viewed upon as getting a report instead of creating a report, and then I'll have a link being passed around. The problem, although I'm not sure it is a problem, is that the customer data can change from day to day and therefore using the link http://myhost/reports/{customerId} can get a report that has different data in it depending on when you access it. But it will always be the report for that specific customer. – per_jansson May 22 '14 at 21:06
  • 1
    `GET myhost/customer/123?aspect="report"&date="05.22.14."` or something like this would not be enough? `GET myhost/customer/123/report?date="05.22.14."` is a viable solution too I think. – inf3rno May 22 '14 at 21:29
  • 1
    In your current case you want to read data which contains the current report of the customer on an exact date. The read data part usually means `GET`. The current report of the customer means `customers/{id}/report` by me. The on the exact date part means `?date="05.22.14."` (or you can use an iso date format) by me. The http method is about what you want to do, the path is about on what resource, the querystring is about the details of the current request. I think I will post a detailed answer. – inf3rno May 22 '14 at 21:38

3 Answers3

2

The POST method isn't a synonym to the create in CRUD. The POST method is used for any operation that isn't standardized, so as long as you document what it does, you're not violating REST, no matter what you do.

There's no such REST principle saying "anything a POST creates should always be accessible via a GET". This is a common misunderstanding due to conflating REST with CRUD. Read this answer for some clarification on that.

In informal language, what a POST says to the server is "take this data and apply it to the resource identified by the given URI, following the rules you documented for the resource media type."

Community
  • 1
  • 1
Pedro Werneck
  • 40,902
  • 7
  • 64
  • 85
0

No, you are not violating REST. As long as your interface is uniform it is up to you to determine what actions the urls of your API perform.

As part of your documentation you simply need to state which methods are valid for certain resources and which aren't. I really like to use the Twitter API as a good example of "What to do"

Example: Twitter REST API

POST statuses/update

does not create an object available for access at

GET statuses/update/3
secretformula
  • 6,414
  • 3
  • 33
  • 56
  • 2
    Not true. This is a misunderstanding of the uniform interface constraint. It's not up to you to determine what actions the urls perform, only the actions involving the POST method. The GET, PUT, PATCH and DELETE methods have well defined actions in the HTTP standard itself, so deviating from that would deviate from the expected interface. – Pedro Werneck May 22 '14 at 21:12
0

The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.

So according to the HTTP standard this is okay.

inf3rno
  • 24,976
  • 11
  • 115
  • 197