11

If you have an API and support the POST operation only because of URL length limitations and the passing of complex parameters in the request, can you still say that you have a RESTful architecture?

What the above basically implies is that for this particular (read-only) API, there is no semantic difference between a GET and a POST, so what can be done with a GET can also be done with a POST (but not vice versa due to the limitations).

Would this still make the style of the architecture a RESTful one?

Andreas Grech
  • 105,982
  • 98
  • 297
  • 360

5 Answers5

5

Technically you are not violating any constraints. However you are severely reducing the self-descriptiveness of requests. This will result in the loss of the ability to cache responses. Being able to cache responses is an essential feature that is needed to build effective REST systems.

Darrel Miller
  • 139,164
  • 32
  • 194
  • 243
  • 2
    +1 This is an important point. I would also suggest that if you are running up against the URL character limit, it might be wise to examine your URL scheme to see if there might be opportunities for refactoring. There can be such a thing as too many query options in the same way you can have too many function or method parameters. – stand May 10 '11 at 17:19
1

You will definitely lose functionality HTTP provides for GET requests. Proxies for instance make certain assumptions about GET requests (idempotence, cachability).

There's nothing wrong with POST perse, but maybe the REPORT method is more appropriate.

Evert
  • 93,428
  • 18
  • 118
  • 189
  • REPORT? That's not a HTTP method. – Darrel Miller May 10 '11 at 11:16
  • @Darren Miller: It's not a standard method, no. But the HTTP specification allows custom methods. – jgauffin May 10 '11 at 11:18
  • Yea it's an extension; just like PATCH and many others. It is indeed in the HTTP specifications that extensions must be allowed. This was one of the goals of HTTP/1.1 I believe. – Evert May 10 '11 at 12:56
  • @jgauffin The HTTP spec allows for extensions if you are prepared to go through the effort of pushing a new public spec through the IETF. It took years for PATCH to be approved `http://tools.ietf.org/html/rfc5789` You "MUST" not just make up your own. – Darrel Miller May 10 '11 at 13:58
  • REPORT is not made up. See: http://tools.ietf.org/html/draft-ietf-httpbis-method-registrations-05 . It has appeared in several HTTP-extensions starting 2002. – Evert May 10 '11 at 14:06
  • Nothing says that the methods have to be methods defined in a standard. It's up to the one implementing a service and his/hers users. – jgauffin May 10 '11 at 14:06
0

The term Representational State Transfer was introduced and defined in 2000 by Roy Fielding in his doctoral dissertation. Section 6.3 explains how to apply REST to HTTP: http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_3

Fielding does not claim that the use of POST is forbidden.

Wikipedia also mentions POST as a legal HTTP operation for RESTful web services: http://en.wikipedia.org/wiki/Representational_State_Transfer#RESTful_web_services

ceving
  • 21,900
  • 13
  • 104
  • 178
  • 1
    Using GET for everything is a violation of the HTTP standard which clearly states that GET should only be used on resources ***that is not being modified***. Quote from the RFC: `the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval`. It's quite important to respect that statement. – jgauffin May 10 '11 at 11:03
  • jgauffin No-one is talking about using GET for unsafe operations, they are talking about using POST for safe operations! – Darrel Miller May 10 '11 at 11:13
  • @jgauffin Of course POST is allowed. That's not the question either. The question is can you use POST for things that would normally be GET. i.e. Safe and idempotent requests. The answer is yes you can, but it is not a good idea. – Darrel Miller May 10 '11 at 11:30
  • I simply corrected ceving before he edited his answer. I've encountered lot's of developers which wants to use GET for all calls. As for the question: It's not relevant what the question says when I'm commenting an (incorrect) answer. – jgauffin May 10 '11 at 11:36
0

So the question here is about restful architecture not for restful web services.If we go by the information given on Wiki-RestfulArch-Constraints , Yes it is.

sudmong
  • 2,036
  • 13
  • 12
0

Why don't you simply switch to including a body in the GET instead of using the query string?

Update

The RFC says the following:

A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request

Theres nothing in the specification that says that a body cannot be included in any of the methods. And all proxies, servers etc are obliged to include the body. It's up to the handler (you) to ignore the body or not.

As for the GET method, nothing states that it can not include a body.

This means that you can use a GET body as long as your web server supports it.

jgauffin
  • 99,844
  • 45
  • 235
  • 372
  • Because the HTTP spec says that a GET body means nothing and could be refused by servers or intermediaries. – Darrel Miller May 10 '11 at 11:20
  • 1
    It is a bad idea though; Even though your http stack should support it, I'd doubt they actually do. There are also no semantics for 'content negitation' based on the request body in GET. (even though technically this is not content-negotation, you can't Vary: the body.. basically). – Evert May 10 '11 at 12:57
  • You are correct. I just tried with `HttpListener` and `HttpWebRequest` in .NET and it didn't work. – jgauffin May 10 '11 at 13:34
  • 1
    When you reference specs it is a good idea to include a link `http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-14#section-7.3` "Bodies on GET requests have no defined semantics. Note that sending a body on a GET request might cause some existing implementations to reject the request." – Darrel Miller May 10 '11 at 13:53
  • In RFC's "SHOULD" has a very precise meaning. Rephrasing it to say "obliged" doesn't really help. Unless the spec says "MUST" you have to deal with the scenario when the rules has not been followed. – Darrel Miller May 10 '11 at 13:56