0

I wanted to clarify on a usecase where i struggled to use GET method for a fetch operation.

I was asked to build a API to generate message from a predefined template. In the request i receive template-ID and the dynamic content which needs to be substituted. Dynamic content vary based on the template-ID.

I have designed like

  1. Method = POST
  2. URL pattern = /messagegenerator/v1/templateID
  3. Body = Dynamic Content in the form of JSON
  4. Response = Plain text message

Problem i faced: When i use GET method then template content should be passed in the URL which has length restriction. We wanted to prepare email message which has more dynamic content.

Ultimately this service won't create any resource but still i forced to use POST method.

Am i missing something?

Rest standard missing?

Is there any better way of doing this?

Is there any restrictions on the length of get URL parameters?

suresh
  • 341
  • 2
  • 3
  • 13

3 Answers3

2

Although there is no url limit in the standard, there is this old advice about keeping your urls under 2000 characters: What is the maximum length of a URL in different browsers?

To the point: in your case sending a POST request with all data in the body is the best solution. Putting email body fragments, or anything that huge (if I understand correctly) into a url is very ugly :). Even if the request does not change anything on the server technically, you should use POST, yes.

Community
  • 1
  • 1
Miklós Tóth
  • 1,490
  • 13
  • 19
0

You need to create a new API which supports http get method, because one API can't receive more than on http method.

chenxi
  • 1
  • 1
0

As you pointed out, in REST the POST method is thought of creating a new resource. In your case a new resource "message" is generated indeed by posting the content even if you do not keep it on the server.

But you are using POST on a template! This should create a new template. To resolve this, add a subresource to the template resource so you can express that it is a message that is created.

I would even extend the URL by adding a "template" after the "v1" to make more explicit that it is the "template" resouce on the first level.

The only change necessary for that would be to modify the URL like this:

URL pattern = /messagegenerator/v1/template/<templateID>/message

So you could have (even if you do not implement it now):

GET on /messagegenerator/v1/template/ -> Deliver a list of templates
POST on /messagegenerator/v1/template/ -> Create a new template
DELETE on /messagegenerator/v1/template/<templateID> -> Remove a template
PUT on /messagegenerator/v1/template/<templateID> -> Modify a template

GET on /messagegenerator/v1/template/<templateID>/message -> Deliver a list of messages
POST on /messagegenerator/v1/template/<templateID>/message -> Create a new message
DELETE on /messagegenerator/v1/template/<templateID>/message/<messageID> -> Remove a message
PUT on /messagegenerator/v1/template/<templateID>/message/<messageID> -> Modify a message

So you could even manage and return old messages if you saved and assigned them an ID!

martinw
  • 364
  • 2
  • 7