4

If a webpage is safe (no serve-side effect) but use POST parameters (to avoid any URL's length issue), then should it be forbidden to call it using GET? Or should each page have some kind of "marker" telling it's safe or unsafe, and forbid GET only on unsafe ones?

First leads to some refactoring here and there to have GET only and POST only pages (and no more "mix"), while second leads to potentially forgotten pages (old ones, and upcoming ones by new developers).

I read the related post "Should I prevent sending of GET requests for urls that are normally operated with POST request?" but that question was for unsafe POST, that obviously must forbid GET. Here, it's about how to globally handle {safe POST that could be called by GET + safe GET + unsafe POST that must not be GET callable}.

Community
  • 1
Xenos
  • 1,381
  • 9
  • 17

2 Answers2

2

The distinction between GET and POST isn't just about safety. In terms of REST (the principle underlying HTTP), the GET method is a "retrieve the information specified in the URL" operation while POST is a "do something to the resource named by the URL" or sometimes "do the operation named by the URL" operation.

If your operation is safe but is not an information retrieval, then it is semantically incorrect to use a GET operation. If your information retrieval requires a query that doesn't fit into the URL length limit, then you probably need to structure your data better so your queries should be less complex. Your clients would appreciate not having to shuffle around a complex data structure just to retrieve the information they need.

Having the same resource operated on by multiple HTTP methods (a "mix") is very common and recommended in REST. Each method generally does different things to the resource, for example you might have an API where you have PUT /transaction/1 creates or updates an uncommitted transaction, PATCH /transaction/1 schedules additional actions to an uncommitted transaction, while POST /transaction/1 executes the transaction and marks it as committed, and GET /transaction/1 to retrieve the transaction detail.

There are many cases though where not all methods make sense in a resource. In that case, you would probably want to issue an HTTP 405 Method Not Allowed response.

Should I forbid GET for non-side effect POST by default?

Generally, you don't want to. That you even think about doing so usually indicates that you might have a design smell or you might have a non-REST API.

xxx
  • 167
  • 8
Lie Ryan
  • 31,459
  • 6
  • 70
  • 94
  • OP isn't talking about REST. Your answer includes the only mentions of REST on this page thus far. Why are you focusing on REST? – user Feb 03 '17 at 15:45
  • It's not a REST I have; still, the same URL could accept GET and POST, but these should be two different handlers? The POST handler should only be triggered for a POST request? – Xenos Feb 03 '17 at 17:21
1

As you've said, for safe POST requests, it doesn't really matter whether they can also be accessed via GET requests. However, this does introduce a usability issue from the point of view of developers. They need to be able to reliably determine whether a given request is safe or not, and to consistently apply the correct rules to those pages.

If they fail to correctly apply a rule to a new page, or make a modification that changes a safe request into an unsafe one on an older page without updating the rules, you potentially get problems.

Therefore, ensuring that all POST requests are treated as "unsafe", even when they may, in specific cases, be "safe" is the fail-safe option. It gives developers a very simple classification: if it uses POST, it doesn't use GET.

This might involve some refactoring in some cases, but this would be a one-off task, whereas keeping up-to-date with changes to safe/unsafe classifications would be an on-going task.

Matthew
  • 27,381
  • 7
  • 91
  • 103