4 ms·

Two Cardinal Sins of REST API Design: Lessons you can Learn from the NewsGator REST API

• lpgauth 18y ago
  Server Error in '/weblog' Application. Could not load file or assembly 'WelcomeMacro' or one of its dependencies. Access is denied.
• pmjordan 18y ago
  Maybe the trouble here is that REST has quite a blurry definition, at least as far as I'm aware. Whenever I try to understand what people really mean by "REST" by researching the topic, the articles I find are either so general and hand-waving that I can't tell what makes a REST interface (except that it uses the HTTP methods correctly) or my brain shuts down from buzzword overload. That said, if anyone can point me at a description that gives some real-world examples of what actually makes a "RESTful" interface, I'd much appreciate being proven wrong.
  • bct 18y ago
    It has a very solid definition (as given in the original thesis http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm ). It's blurred because a lot of people latch onto the wrong things or get it wrong and spread those misconceptions. This introduction isn't bad: http://www.infoq.com/articles/rest-introduction http://www.infoq.com/articles/rest-introduction In short: you have nouns and representations of nouns. You have a set of verbs that can be applied to those nouns. You discover nouns through links from other nouns. The client and the server exchange state by exchanging representations. The server doesn't need to know what the client is doing at a particular moment.
    • ajross 18y ago
      It's also blurred because people try to apply it to problems for which isn't not appropriate. The central theme of REST is that a single URI corresponds uniquely to a single "thing", which is then operated on using a small set of operations (basically set/get/delete). That's great, if your problem works like that. It's not great if it doesn't. Some protocols really are more appropriately modelled using "methods" on the objects, because the behavior is what matters, not so much the data itself.
      • bct 18y ago
        Can you give an example?
        • ajross 18y ago
          Of protocols that don't work well with REST? Sure: anything that, in the database world, would require transactions. Think of the classic double-entry accounting transaction: you have two accounts, and need to atomically subtract an amount from one and add it to the other. Clearly the accounts are two (or more) REST URIs. But the operation needs to be atomic on both; it's not enough just to do two PUT/POST operations. You can do it with REST, but it requires some fancy footwork with extra objects for "locks" or whatnot. It's just a mess. With a protocol that exposes behavior instead of state? It's just a "DEBIT" command that takes two accounts and an amount and returns success or failure. Basically: pick the tool for the job. A lot of the "problems" with REST are an attempt to make the hype more powerful than the technique.
          • bct 18y ago
            The RESTful way to do that would be something like: POST /transactions from: /accounts/savings to: /accounts/chequing amount: 123.45 Generally the proper way to do something atomically is to do it in a single request. REST isn't the best choice for every application - the whole point is that it has certain strengths - but it's very flexible.
            • ajross 18y ago
              No, no, no. That's not RESTful at all. What "thing" does /transactions represent? It's the same URI for every single account in the world? What you've done is break out of the paradigm in order to solve a particular problem, which is great. But don't call it "REST", because the whole point of this discussion is that doing so confuses people about what REST is supposed to mean.
              • bct 18y ago