3 ms·

Curious, what could you have against REST, and is it only the JSON incarnation?

• lmm 12y ago
  I think the big advantage of "REST" was being easy to use from the browser, but modern REST (with e.g. content negotiation and HTTP verbs) actually goes against that. I think strict, automatically-checked schemata for APIs are very valuable, so I'd prefer to use something like thrift or even WS-* rather than REST.
  • lloeki 12y ago
    > think strict, automatically-checked schemata for APIs are very valuable, so I'd prefer to use something like thrift or even WS-* rather than REST. Strict, automatically-checked schemata for APIs are perfectly doable with REST, JSON or whatever Protobuf flavor. OTOH automatically-generated schemata behemoths have been created with SOAP and WS-* that I have very creative ideas about how to deal with and dispose of. As for the easy-in-the-browser part (whether it is for tests or implementation), it was merely a side effect of reusing the HTTP spec semantics as a common-ground general purpose vocabulary. REST in itself doesn't even mandate HTTP.
    • lmm 12y ago
      > Strict, automatically-checked schemata for APIs are perfectly doable with REST, JSON or whatever Protobuf flavor. Up to a point, but having a single standard that's built into all the tooling is huge. Hopefully one or other approach will "win" in the REST world and we'll start to see some convergence. > As for the easy-in-the-browser part (whether it is for tests or implementation), it was merely a side effect of reusing the HTTP spec semantics as a common-ground general purpose vocabulary. Intended or otherwise, it was a big advantage, and I think it was the real reason for "REST"'s success.