4 ms·

> Lastly, you’re no longer allowed to define a response for GET and DELETE (which matches how RESTful APIs work). I get that part about the DELETE, but no resp

by Dunedan 10y ago

> Lastly, you’re no longer allowed to define a response for GET and DELETE (which matches how RESTful APIs work). I get that part about the DELETE, but no response for GET sounds odd. As I couldn't find anything in the spec RC: Is there further information available regarding that?

smizell 10y ago
Total guess, but they may mean request bodies instead of response since GET and DELETE normally don't have request bodies. However, I'm not sure there is a definitive answer on if that's true from an HTTP perspective. I also couldn't find it in a skimming of the OpenAPI 3.0 spec. In the end, REST [1] itself does not prescribe either condition and the HTTP 1.1 [2] spec doesn't either. > A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request. [1] https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... [2] https://tools.ietf.org/html/rfc7231#section-4.3.1 https://tools.ietf.org/html/rfc7231#section-4.3.1
- johnhenry 10y ago
  I tend to agree with the interpretation given here: http://stackoverflow.com/questions/978061/http-get-with-request-body http://stackoverflow.com/questions/978061/http-get-with-requ... -- that if a GET request contains a body, the server should ignore it in order to stay compliant with the spec.
gkoberger 10y ago
Sorry, typo. Should be "request bodies"!
- darrelmiller 10y ago
  Yes, we decided to be opinionated and say you can't describe bodies for operations where the spec says bodies have no meaning. The text should be there, but I think the RC0 revision has some formatting issues that is hiding the text.
  - bpicolo 10y ago
    Isn't that the older spec which has been replaced by new RFCs though? Thought that's what I read earlier this week. RFC 7230-7237 got rid of that expectation it seems? Imo, a flaw in the earlier spec. It's clearly the case that people have uses for requesting data via JSON, and GET is the only thing that fits expected semantics ATM. Elasticsearch takes json over GET bodies because it just makes sense.
    - davidbiesack 10y ago
      RFC 7231 4.3.1 GET says A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request. https://tools.ietf.org/html/rfc7231#section-4.3.1 https://tools.ietf.org/html/rfc7231#section-4.3.1
      - bpicolo 10y ago
        Seems looser. Regardless, it does make sense for a number of applications to have a better query language than query-strings, or base64-nonsense-via-query strings, heh.
        darrelmiller 10y ago
        The text is different but the meaning is the same. A GET body must not have an effect on the request/response. i.e. You can have one, but you are not allowed to use it for anything.
        bpicolo 10y ago
        That's not how I interpret it. I don't read "has no defined semantics" as "you can't make up your own". All that says to me is that the RFC doesn't explicitly define any semantics. The other line I would guess is there because in the past the RFC was worded a bit differently, such that there's tech (webservers or whatever) out there that ignores request bodies on GET, so using it may lead to issues using those pieces of tech. You can really do whatever you want. I'm not a fan of restrictive/pedantic intepretations of the spec, because HTTP is necessarily something that is really up to the developer in every way. Your database sure doesn't care if it's doing a non-idempotent write as a result of a web request that was a PUT. Spec or not, it makes sense to be able to support a richer query language through the only HTTP verb specified for retrieving data. Just accepting that as something we can't do because some RFCs say this or that is a bit silly, because most apps out there can support it just fine. Elasticsearch is a much better piece of software because it ignored that bit of advice. (And I've had no problems running Elasticsearch through various different proxy layers, so software like nginx /haproxy also don't seem to care if you use a GET request body).

by Dunedan 10y ago

smizell 10y ago

Total guess, but they may mean request bodies instead of response since GET and DELETE normally don't have request bodies. However, I'm not sure there is a definitive answer on if that's true from an HTTP perspective. I also couldn't find it in a skimming of the OpenAPI 3.0 spec. In the end, REST [1] itself does not prescribe either condition and the HTTP 1.1 [2] spec doesn't either. > A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request. [1] https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... [2] https://tools.ietf.org/html/rfc7231#section-4.3.1 https://tools.ietf.org/html/rfc7231#section-4.3.1

johnhenry 10y ago
I tend to agree with the interpretation given here: http://stackoverflow.com/questions/978061/http-get-with-request-body http://stackoverflow.com/questions/978061/http-get-with-requ... -- that if a GET request contains a body, the server should ignore it in order to stay compliant with the spec.

gkoberger 10y ago

Sorry, typo. Should be "request bodies"!

darrelmiller 10y ago
Yes, we decided to be opinionated and say you can't describe bodies for operations where the spec says bodies have no meaning. The text should be there, but I think the RC0 revision has some formatting issues that is hiding the text.
- bpicolo 10y ago
  Isn't that the older spec which has been replaced by new RFCs though? Thought that's what I read earlier this week. RFC 7230-7237 got rid of that expectation it seems? Imo, a flaw in the earlier spec. It's clearly the case that people have uses for requesting data via JSON, and GET is the only thing that fits expected semantics ATM. Elasticsearch takes json over GET bodies because it just makes sense.
  - davidbiesack 10y ago
    RFC 7231 4.3.1 GET says A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request. https://tools.ietf.org/html/rfc7231#section-4.3.1 https://tools.ietf.org/html/rfc7231#section-4.3.1
    - bpicolo 10y ago
      Seems looser. Regardless, it does make sense for a number of applications to have a better query language than query-strings, or base64-nonsense-via-query strings, heh.
      - darrelmiller 10y ago
        The text is different but the meaning is the same. A GET body must not have an effect on the request/response. i.e. You can have one, but you are not allowed to use it for anything.
        bpicolo 10y ago
        That's not how I interpret it. I don't read "has no defined semantics" as "you can't make up your own". All that says to me is that the RFC doesn't explicitly define any semantics. The other line I would guess is there because in the past the RFC was worded a bit differently, such that there's tech (webservers or whatever) out there that ignores request bodies on GET, so using it may lead to issues using those pieces of tech. You can really do whatever you want. I'm not a fan of restrictive/pedantic intepretations of the spec, because HTTP is necessarily something that is really up to the developer in every way. Your database sure doesn't care if it's doing a non-idempotent write as a result of a web request that was a PUT. Spec or not, it makes sense to be able to support a richer query language through the only HTTP verb specified for retrieving data. Just accepting that as something we can't do because some RFCs say this or that is a bit silly, because most apps out there can support it just fine. Elasticsearch is a much better piece of software because it ignored that bit of advice. (And I've had no problems running Elasticsearch through various different proxy layers, so software like nginx /haproxy also don't seem to care if you use a GET request body).