5

I am writing a little app that does one thing only: takes some user-provided data, does some analysis on it, and returns a "tag" for that data. I am thinking that the client should either GET or POST their request to /getTag in order to get a response back.

Nothing is stored on the server when the client does this, so it feels weird to use a POST. However, there is not a uniform URI for the analysis either, so using a GET feels weird, since it will return different things depending on what data is provided.

What is the best way to represent this functionality with REST?

Jamison Dance
  • 19,896
  • 25
  • 97
  • 99

5 Answers5

2

The "best way" is to do whatever is most appropriate for your application and its needs. Not knowing that, here are a few ideas:

  1. GET is the most appropriate verb since you're not creating or storing anything on the server, just retrieving something that the server provides.

  2. Don't put the word get in the URI as you've suggested. Verbs like that are already provided by HTTP, so just use /tag and GET it instead.

  3. You should use a well-understood (or "cool") URI for this resource and pass the data as query parameters. I wouldn't worry about it feeling weird (see this question's answers to find out why).

To sum up, just GET on /tag?foo=bar&beef=dead, and you're done.

Community
  • 1
  • 1
Brian Kelly
  • 19,067
  • 4
  • 53
  • 55
1

POST can represent performing an action. The action doesn't have to be a database action.

What you have really created is a Remote Procedure. RPC is usually all POST. I don't think this is a good fit for REST, but that doesn't have to stop you from using simple URLs and JSON.

Sean Clark Hess
  • 15,859
  • 12
  • 52
  • 100
1

It seems to me like there would probably be a reason you or the user who generated the original data would want the generated tag to persist, wouldn't they?

If that's a possibility, then I'd write it as POST /tags and pass the /tags/:id resource URI back as a Location: header.

If I really didn't care about persisting the generated tag, I'd think about what the "user-generated data" was and how much processing is happening behind the scenes. If the "tag" is different enough from whatever data is being passed into the system, GET /tag might be really confusing for an API consumer.

rhodesjason
  • 4,904
  • 9
  • 43
  • 59
0

I'll second Brian's answer: use a GET. If the same input parameters return the same output, and you're not really creating anything, it's an idempotent action and thus perfectly suited for a GET.

Dan Dorman
  • 21
  • 2
0

You can use GET and POST either:

  • GET /tag?data="..." -> 200, tag

    The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process.

  • POST /tag {data: "..."} -> 200, tag

    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.

according to the HTTP standard / method definitions section.

I would use GET if I were you (and POST only if you want to send files).

inf3rno
  • 24,976
  • 11
  • 115
  • 197