4 ms·

I just started at a new job, at a new startup. During the my first job interview with them, they asked, "Do you know how to work with a RESTful interface?" I s

I just started at a new job, at a new startup. During the my first job interview with them, they asked, "Do you know how to work with a RESTful interface?" I said yes, and I told them to look at my Github account for examples. During my second job interview with them, they asked "What do you consider when you are designing a RESTful interface?" I quoted a bit from the book that Sam Ruby and Leonard Richardson wrote, back in 2007, and which I've read cover to cover. Among other things, I said the overall goal should be to work with HTTP, not against it. Then their lead programmer tried to ask me what he apparently thought was a "trick" question. (He was quitting the startup to go back to school, and I was being hired to replace him.) He asked, if, for a given task, HTTP was too verbose a protocol, then what else might I use for a RESTful interface. I suppose that should have been my first warning. I wasn't sure what they were looking for, but I thought maybe they wanted me to say WebSockets, or perhaps they wanted me to push back against the question and ask why HTTP was too verbose, or they wanted me to suggest the use of TCP in an ad-hoc style that mimicked HTTP. I explored all those possible answers as I spoke with them. Then I was hired and I started the job. Their system is not RESTful at all. The only HTTP verb they use is POST. They use it for everything, and they put all their data in the body of the POST. Their system is pure RPC, with a style influenced by SOAP. The people I'm working with are in their early to mid 20s. I'm not sure if age is a factor, since I've seen the same mistake made by programmers in their 50s. But, for sure, there are some programmers who do not seem to know the difference between RPC and RESTful. Of course, on a personal level, none of that really matters. I really like this place that I'm now working, and I'm happy to work with their RPC style. I have, however, insisted that we use correct terminology, just for the sake of clarity.

mgkimsal 11y ago
I've seen that, and even been "guilty" of it myself years ago - many people take 'RESTful' to just mean anything that returns JSON instead of a full HTML document.
- Drdrdrq 11y ago
  I usually use the term "REST" instead of RESTful - I know and understand the benefits of pure REST but I choose JSON over XML every time I can. Not to mention suboptimal support for PUT / DELETE / ... methods in Apache.
  - nearengine 11y ago
    REST is an architectural pattern that specifies properties about the interface, not the data - how does using JSON over XML make your interface not RESTful? In his dissertation[1], Roy Fielding always refers to data in terms of resources rather than specific formats. [1] https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...
    - icebraining 11y ago
      I think the idea that JSON isn't "REST" is because, unlike XML, it doesn't define links. That said, JSON is just an encoding format. The actual response format is not "JSON", but the specific structure that your clients are expecting to receive (even if it is encoded in JSON), and that can certainly have links.
aikah 11y ago
> Their system is not RESTful at all IHMO ,The problem is nobody has a clue what REST or RESTful really means,at least I don't. But it's clearly not a protocol. It's not even a well defined pattern that exposes clear behaviors with rules. Some developers don't like that, they want clear goals to do their work and want canonical examples they can point to when arguing with colleagues. So personally I understand the appeal for RPC : No semantics , no arguing about whether one should use PUT, POST or PATCH and when , whether links should be headers or in the body, or about which JSON/XML bloated spec to use to make an API HATEOAS...
- icebraining 11y ago
  REST is well defined, it's just that most guides don't explain it well. REST is just a list of 6 possible characteristics of network protocols/architectures (Client/Server, Stateless, Cache, etc), and an explanation of the benefits gained by having them. That said, it's true that REST by itself doesn't tell you how to build an API. But all of that arguing about PUT/POST/PATCH, links here or there, etc, are mostly bikeshedding. It's like arguing for tabs vs spaces or whether the { should go inline or not. Just read the HTTP spec and then, when in doubt, just pick one and try to be consistent. But you're right that many programmers don't deal well with that. It'd be nice to have some kind of reference protocol using HTTP & JSON and complying with REST, even if it would be as arbitrary as any other possible RESTful protocol.
mariodiana 11y ago
To a good number of people, "REST" means the Web—but not SOAP. Mapping CRUD to HTTP methods, and so forth, completely escapes some people. "REST good. I want." That's as far as some thinking goes :-(

mgkimsal 11y ago

I've seen that, and even been "guilty" of it myself years ago - many people take 'RESTful' to just mean anything that returns JSON instead of a full HTML document.

Drdrdrq 11y ago
I usually use the term "REST" instead of RESTful - I know and understand the benefits of pure REST but I choose JSON over XML every time I can. Not to mention suboptimal support for PUT / DELETE / ... methods in Apache.
- nearengine 11y ago
  REST is an architectural pattern that specifies properties about the interface, not the data - how does using JSON over XML make your interface not RESTful? In his dissertation[1], Roy Fielding always refers to data in terms of resources rather than specific formats. [1] https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...
  - icebraining 11y ago
    I think the idea that JSON isn't "REST" is because, unlike XML, it doesn't define links. That said, JSON is just an encoding format. The actual response format is not "JSON", but the specific structure that your clients are expecting to receive (even if it is encoded in JSON), and that can certainly have links.

aikah 11y ago

> Their system is not RESTful at all IHMO ,The problem is nobody has a clue what REST or RESTful really means,at least I don't. But it's clearly not a protocol. It's not even a well defined pattern that exposes clear behaviors with rules. Some developers don't like that, they want clear goals to do their work and want canonical examples they can point to when arguing with colleagues. So personally I understand the appeal for RPC : No semantics , no arguing about whether one should use PUT, POST or PATCH and when , whether links should be headers or in the body, or about which JSON/XML bloated spec to use to make an API HATEOAS...

icebraining 11y ago
REST is well defined, it's just that most guides don't explain it well. REST is just a list of 6 possible characteristics of network protocols/architectures (Client/Server, Stateless, Cache, etc), and an explanation of the benefits gained by having them. That said, it's true that REST by itself doesn't tell you how to build an API. But all of that arguing about PUT/POST/PATCH, links here or there, etc, are mostly bikeshedding. It's like arguing for tabs vs spaces or whether the { should go inline or not. Just read the HTTP spec and then, when in doubt, just pick one and try to be consistent. But you're right that many programmers don't deal well with that. It'd be nice to have some kind of reference protocol using HTTP & JSON and complying with REST, even if it would be as arbitrary as any other possible RESTful protocol.

mariodiana 11y ago

To a good number of people, "REST" means the Web—but not SOAP. Mapping CRUD to HTTP methods, and so forth, completely escapes some people. "REST good. I want." That's as far as some thinking goes :-(