5 ms·

99.9% What? Has nobody on HK ever used REST either as a consumer or producer? http://en.wikipedia.org/wiki/Representational_state_transfer#Vocabulary_re-use_vs

99.9% What? Has nobody on HK ever used REST either as a consumer or producer? http://en.wikipedia.org/wiki/Representational_state_transfer#Vocabulary_re-use_vs._its_arbitrary_extension:_HTTP_and_SOAP http://en.wikipedia.org/wiki/Representational_state_transfer...

jscheel 13y ago
Problem is, in a lot of circumstances, you still have to rely on GET and POST with a header like X-REQUEST-METHOD set to tell the server what you really meant.
- dragonwriter 13y ago
  Usually, this is not the server not supporting it, its a workaround that the server provides so that you can consume the API without AJAX from HTML forms, which are restricted to GET and POST. EDIT: Although in some cases there is an issue that people choose not to configure it on the web server, and instead use headers or other mechanisms to tunnel the "real" method to the application. But most servers do support it, this seems to be a mechanism for routing around administrative issues in organizations.
  - danabramov 13y ago
    “But most servers do support it, this seems to be a mechanism for routing around administrative issues in organizations.” Spot on.
metaphorm 13y ago
sure we have. have you read through the developer docs for most API's? here's twitters: https://dev.twitter.com/docs/api/1.1 https://dev.twitter.com/docs/api/1.1 its all GET and POST. this is typical.
- YellowRex 13y ago
  I just wrote a REST API for my company and used PUT and DELETE (Tomcat doesn't support PATCH yet). Plenty of DELETE in Stripe's API: https://stripe.com/docs/api#delete_recipient https://stripe.com/docs/api#delete_recipient Github uses HEAD, PATCH, PUT, and DELETE: http://developer.github.com/v3/#http-verbs http://developer.github.com/v3/#http-verbs Twilio supports PUT and DELETE: http://www.twilio.com/docs/api/rest/request http://www.twilio.com/docs/api/rest/request There are all darlings of the HK community with highly praised, widely used REST APIs. Have you read through the developer docs for most APIs? (edit: typo)
  - ramchip 13y ago
    To be fair to the other poster, I wouldn't be surprised if 99.9% of requests were GET/POST/HEAD.
    - Gigablah 13y ago
      And 99.9% of requests are GET rather than POST, so shall we get rid of POST then?
      - shawnz 13y ago
        GET and POST already have widely observed distinctions in how they should be handled. For example, try hitting refresh on a page that was arrived at via a POST request. That behaviour is pretty much common to all browsers.
      - tericho 13y ago
        His point was that at minimum you still need a GET and POST for read and write. So comparing the numbers against bike-shed implementations is moot. Of course the number of reads will be significantly higher.
        icebraining 13y ago
        You could write and read using just POST. SOAP is the living example of that. So I think his point is inconsistent.

jscheel 13y ago

Problem is, in a lot of circumstances, you still have to rely on GET and POST with a header like X-REQUEST-METHOD set to tell the server what you really meant.

dragonwriter 13y ago
Usually, this is not the server not supporting it, its a workaround that the server provides so that you can consume the API without AJAX from HTML forms, which are restricted to GET and POST. EDIT: Although in some cases there is an issue that people choose not to configure it on the web server, and instead use headers or other mechanisms to tunnel the "real" method to the application. But most servers do support it, this seems to be a mechanism for routing around administrative issues in organizations.
- danabramov 13y ago
  “But most servers do support it, this seems to be a mechanism for routing around administrative issues in organizations.” Spot on.

metaphorm 13y ago

sure we have. have you read through the developer docs for most API's? here's twitters: https://dev.twitter.com/docs/api/1.1 https://dev.twitter.com/docs/api/1.1 its all GET and POST. this is typical.

YellowRex 13y ago
I just wrote a REST API for my company and used PUT and DELETE (Tomcat doesn't support PATCH yet). Plenty of DELETE in Stripe's API: https://stripe.com/docs/api#delete_recipient https://stripe.com/docs/api#delete_recipient Github uses HEAD, PATCH, PUT, and DELETE: http://developer.github.com/v3/#http-verbs http://developer.github.com/v3/#http-verbs Twilio supports PUT and DELETE: http://www.twilio.com/docs/api/rest/request http://www.twilio.com/docs/api/rest/request There are all darlings of the HK community with highly praised, widely used REST APIs. Have you read through the developer docs for most APIs? (edit: typo)
- ramchip 13y ago
  To be fair to the other poster, I wouldn't be surprised if 99.9% of requests were GET/POST/HEAD.
  - Gigablah 13y ago
    And 99.9% of requests are GET rather than POST, so shall we get rid of POST then?
    - shawnz 13y ago
      GET and POST already have widely observed distinctions in how they should be handled. For example, try hitting refresh on a page that was arrived at via a POST request. That behaviour is pretty much common to all browsers.
    - tericho 13y ago
      His point was that at minimum you still need a GET and POST for read and write. So comparing the numbers against bike-shed implementations is moot. Of course the number of reads will be significantly higher.
      - icebraining 13y ago
        You could write and read using just POST. SOAP is the living example of that. So I think his point is inconsistent.