5 ms·

RESTful doesn't mean anything no more than REST means anything, precisely because it's NOT A PROTOCOL and THERE IS NO NORMATIVE SPEC. All this fiasco is due to

by aikah 11y ago

RESTful doesn't mean anything no more than REST means anything, precisely because it's NOT A PROTOCOL and THERE IS NO NORMATIVE SPEC. All this fiasco is due to a vague set of ideas that are in practice no more than JSON-RPC with a http header. I'm sure you can find 50 developers that will disagree on your definition and that's what hurts all the REST advocates. Your definition is as valid as theirs, until there is a spec that explains precisely what REST is. There is none, there is no normative spec, period. SOAP has a spec, RPC has a spec, GraphQL has a spec. "REST"(full) has no spec, REST is whatever you think it is.

steveklabnik 11y ago
> There is none There isn't a singular spec, no, because REST describes an _set_ of architectures. A family of them. But there is a pretty easy test: do you follow the 6 constraints (though one is optional)? If the answer is yes, then it's RESTful.
tarr11 11y ago
REST seems to be an API design pattern, rather than a spec. You can't build a standard REST client since there is no spec, but you can build a libraries that mostly work, since you can identify the pattern quickly.
- jonhohle 11y ago
  But what would that library do? Map discrete input to serialized resource identifiers? Encode or decode resource payloads? Provide transport abstraction? Oh, REST doesn't have an opinion on any of the practical, tangible things a library would implement. Those are always left to the service author without an advertising mechanism for clients.
  - tarr11 11y ago
    It doesn't always work, but when it does, its better than having to support an explosion of SDK wrappers that all essentially do the same thing (e.g, provide the services you mention)
- vram22 11y ago
  >REST seems to be an API design pattern, rather than a spec. IIRC, in an article by Roy Fielding that I read, he said that REST is an architectural style.
deleted 11y ago
[deleted]
mwcampbell 11y ago
> REST is whatever you think it is. Nonsense. REST is what Dr. Fielding says it is, because he coined the term.
- t-schill 11y ago
  And REST as Dr. Fielding says it is is not as practical to implement as it should be. Hence the need for RESTful which just draws influence from his work.
  - mwcampbell 11y ago
    What makes REST impractical? And if REST isn't practical, we should use a different term to describe what we implement instead. The meanings of words should be immutable, to avoid confusion. No, that's not how language has historically worked, but we can do better. After all, there are a lot of things we have historically done that we don't want to keep doing.
    - dvanduzer 11y ago
      Why would speaking a human language without nuance, without any possibility of misinterpretation, be a step forward? It's spelled ReST. Does that better convey what it means in that string of characters? Maybe for some values of human. But words are for humans, and humans are not immutable, so our words shouldn't be.
      - antod 11y ago
        > It's spelled ReST. Really? It's been capitalized REST everywhere I've seen it. Including here: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch... You weren't thinking of 'reST' (reStructuredText) were you?
        dvanduzer 11y ago
        No, I was thinking of Representational State Transfer, which is what Fielding's paper talks about. And I was also thinking about how people say RESTful, and how that's a confusing way to say "conforms to how Roy Fielding thinks an API should behave." What I was responding to was advocacy that human language should behave the way we expect RFCs to work.
tie_ 11y ago
> ...set of ideas that are in practice no more than JSON-RPC with a http header. I'd argue that JSON-RPC (as well as XML-RPC) is more useful than REST, as it has a simple specification that any client/server could follow. If you write a JSON-RPC server, you can expect that any JSON-RPC client would be able to use it.

by aikah 11y ago

steveklabnik 11y ago

> There is none There isn't a singular spec, no, because REST describes an _set_ of architectures. A family of them. But there is a pretty easy test: do you follow the 6 constraints (though one is optional)? If the answer is yes, then it's RESTful.

tarr11 11y ago

REST seems to be an API design pattern, rather than a spec. You can't build a standard REST client since there is no spec, but you can build a libraries that mostly work, since you can identify the pattern quickly.

jonhohle 11y ago
But what would that library do? Map discrete input to serialized resource identifiers? Encode or decode resource payloads? Provide transport abstraction? Oh, REST doesn't have an opinion on any of the practical, tangible things a library would implement. Those are always left to the service author without an advertising mechanism for clients.
- tarr11 11y ago
  It doesn't always work, but when it does, its better than having to support an explosion of SDK wrappers that all essentially do the same thing (e.g, provide the services you mention)
vram22 11y ago
>REST seems to be an API design pattern, rather than a spec. IIRC, in an article by Roy Fielding that I read, he said that REST is an architectural style.

deleted 11y ago

[deleted]

mwcampbell 11y ago

> REST is whatever you think it is. Nonsense. REST is what Dr. Fielding says it is, because he coined the term.

t-schill 11y ago
And REST as Dr. Fielding says it is is not as practical to implement as it should be. Hence the need for RESTful which just draws influence from his work.
- mwcampbell 11y ago
  What makes REST impractical? And if REST isn't practical, we should use a different term to describe what we implement instead. The meanings of words should be immutable, to avoid confusion. No, that's not how language has historically worked, but we can do better. After all, there are a lot of things we have historically done that we don't want to keep doing.
  - dvanduzer 11y ago
    Why would speaking a human language without nuance, without any possibility of misinterpretation, be a step forward? It's spelled ReST. Does that better convey what it means in that string of characters? Maybe for some values of human. But words are for humans, and humans are not immutable, so our words shouldn't be.
    - antod 11y ago
      > It's spelled ReST. Really? It's been capitalized REST everywhere I've seen it. Including here: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch... You weren't thinking of 'reST' (reStructuredText) were you?
      - dvanduzer 11y ago
        No, I was thinking of Representational State Transfer, which is what Fielding's paper talks about. And I was also thinking about how people say RESTful, and how that's a confusing way to say "conforms to how Roy Fielding thinks an API should behave." What I was responding to was advocacy that human language should behave the way we expect RFCs to work.

tie_ 11y ago

> ...set of ideas that are in practice no more than JSON-RPC with a http header. I'd argue that JSON-RPC (as well as XML-RPC) is more useful than REST, as it has a simple specification that any client/server could follow. If you write a JSON-RPC server, you can expect that any JSON-RPC client would be able to use it.