5 ms·

At least the author is wise enough to see that REST/RPC are not so different from each other. I actually find it interesting that as I was learning about earli

• deleted 12y ago
  [deleted]
• steveklabnik 12y ago
  "Layman's REST" is very much RPC, yes. Fielding's REST is very much not.
  • mantrax5 12y ago
    Fielding's REST is pretty much CRUD in HTTP disguise. Don't get me wrong, this can be great for "hypermedia applications" as Fielding's paper argues. But "hypermedia applications" just doesn't fit what many distributed services do these days. Services are naturally centered arounds verbs (commands and queries) and not nouns (resources), so like with any other CRUD system, at some point a REST API that shoehorns everything into the four standard verbs HTTP commonly gives us, no longer adequately describes the business requirements of your app. You can definitely force things to be RESTful, but it's typically not the natural way to build an API. Feels akin to the ORM kind of impedance mismatch in some ways.
    • icedchai 12y ago
      Exactly this. I've seen people doing crazy, non-nonsensical stuff to make their APIs "RESTful". So RESTful that they make no sense.
    • steveklabnik 12y ago
      I agree that many services are simply CRUD wrappers. That doesn't have much to do with the nature of the architecture Fielding proposes. I would be interested in some citations from Fielding which demonstrate that RPC is its organizational principle. I don't think they're there, though.
      • beamatronic 12y ago
        I'm surprised someone hasn't embraced the idea and built the ultimate generic CRUD wrapper
        • steveklabnik 12y ago
          They often fail. See ActiveResource, for example.
      • deleted 12y ago
        [deleted]
      • mantrax6 12y ago
        Fieldman's work doesn't exist in vacuum. He talks about HTTP, and HTTP has the verbs it has. It's hard enough to find consistent behavior in HTTP servers and proxies with "PUT" and "DELETE" let alone anything else. But even ignoring that, the verbs the spec talks about are limited. And that's a big problem. As for RPC, essentially any communication between machines is a RPC. It's message passing ("call") and if the message arrives on the other end it's processed by a message handler ("procedure"). No server can just reach into another server's RAM and get or modify a resource directly. The interaction happens entirely by the will of the message receiver, and in exactly the way the receiver wants (not the sender). So if we'll be building everything on an appropriate abstraction, it better match what really happens (messages, message handlers) and not some wishful thinking abstraction layered on top (resources, resource modification). RPC is not REST's problem. The problem is the limited commands (PUT, POST, DELETE) and the single possible query type (GET) that we need to work with. When a payment gateway has to represent a simple "process payment" command with a series of bogus abstractions like a "POST /payment/transaction/new", you know REST is the wrong tool for the job.
    • scotth 12y ago
      Aside: Why do you have so many accounts mantrax? At least one of them is dead, and I'm sure you can imagine why.
      • mantrax7 12y ago
        None of them are dead. As for why, long story short, because HackerNews is really poorly written. For example I can't even reply from mantrax5 right now.
      • mantrax6 12y ago
        None of them are dead. As for why, long story short, because HackerNews' code is really poorly written. Gateway errors, horrendous response times, bogus limits and false positives. My usage patterns are likely not typical, but this is hardly an excuse for such a poor UX. For example, I couldn't even respond right now through mantrax5... Next time I'll just take the alternative and instead of making more accounts, I'll just stop visiting the site completely.
        • ademarre 12y ago
          Have you reported these HN bugs?
      • scotth 12y ago
        HN hellbans, so you might not realize you're not being heard. I'm seeing [dead] markers from matrax6 and mantrax7 (although oddly enough, not consistently). Can't comment on the quality of the code. Your problems sound atypical.
    • ademarre 12y ago
      The problem with REST is that many (I dare say most) who think they are applying it really aren't. I think this is quite relevant: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte... What sets REST apart from RPC is the Hypermedia-as-the-Engine-of-Application-State principle (HATEOAS). With HATEOAS, interaction semantics are removed from URIs and defined in terms of link relations. This decouples clients from URIs; very valuable. ADD: To equate REST with CRUD overlooks HATEOAS completely. Simple CRUD solutions work on resources that have already been identified, but HATEOAS adds resource identification/addressing and discovery in a very maintainable way.
      • steveklabnik 12y ago
        While I agree with you that that's certainly an interesting part of the split between RPC and REST, you might be curious to know that Fielding doesn't think so. > What makes HTTP significantly different from RPC is that the requests are directed to resources using a generic interface with standard semantics that can be interpreted by intermediaries almost as well as by the machines that originate services. http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_5_2 http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluatio...
        • ademarre 12y ago
          Interesting, thank you; but in that quote isn't Fielding actually comparing RPC and HTTP, not REST?
          • steveklabnik 12y ago
            Yes, you're right, I was being a bit sloppy there. The Uniform Interface (and Layered System) is one of the ways in which HTTP does follow RESTful principles, though, so the thrust is still the same.
            • ademarre 12y ago
              Agreed. But I think it's a stretch to conclude that Fielding doesn't think the hypermedia principle is an important distinction between RPC and REST: From his blog post I linked to earlier, titled REST APIs must be hypertext-driven [0]: > "I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Today’s example is the SocialSite REST API. That is RPC. It screams RPC. There is so much coupling on display that it should be given an X rating. "What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint?" [0] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...
    • bodhi 12y ago
      So, honest question. I've been musing over REST and RPC for a while, and was trying to come up with some domains that were verb-oriented instead of noun-oriented. The only thing I could come up with was message passing, a-la XMPP or streaming content. What are some other problem domains that are better represented in verb-oriented terminology?
      • programminggeek 12y ago
        I think when an action affects multiple nouns at the same time, it starts to look more like a verb oriented approach. For example, say you have some kind of fundraising event donation system where you can have a donor donate to people or teams of people participating at the event as well as the event itself or the organization as a whole. So, something like a 5k run to save the whales. When you create a donation that impacts potentially an auth record and a user account (if they create one), a donation, as well a it could end up touching the event, participant, team, or organization itself. Now, do you make all those data changes as a series of nouns with actions that you must do in some particular workflow and order? Or, do you have a higher level verb that you throw input at and it returns a result, doing whatever it needs to do in the process? Or do you have a noun with a single verb that starts to feel a lot like RPC? In some ways they are equivalent, you have input, state change, and output. In other ways they are different. I would expect in REST you might have to hit multiple nouns to change all the state appropriately and I'm not sure there is a good mechanism to enforce that it happens correctly according to the desired workflow. In the end, for things beyond CRUD and reporting, I think complex actions that touch multiple verbs is often better represented as a verb. However, I would love to see concrete examples of how you model complex workflow based state changes as a "transaction" or workflow in REST or if REST api's inherently opt out of such behavior.
        • steveklabnik 12y ago
          > I would expect in REST you might have to hit multiple nouns to change all the state appropriately In layman's REST, yes. In Fielding's REST, no. It's one of the serious ways in which layman's REST is deficient.
        • 12y ago
    • dreamfactory2 12y ago
      > Services are naturally centered arounds verbs (commands and queries) and not nouns (resources) Can you qualify that? Queries are presumably queries on resources, and which commands did you have in mind apart from creating or updating resources?
      • cfallin 12y ago
        Not OP, but a thought anyway: these worldviews are sort of duals of each other, IMHO. You can consider a "noun" to be one instance of a verb's application, i.e., an action. For example, "send an email" or "purchase an item", both verbs, translate to creating new nouns representing (respectively) an email in my Outbox or a transaction. The advantage of the noun worldview is that the nouns can describe the history of verbs and the resulting application state, e.g., I can look at and manage the whole ledger of transactions, whereas verbs are just ad-hoc manipulations of that state.
    • grey-area 12y ago
      I think the reason people limit verbs (or nouns) usually comes down to attempting to limit the gestalt which others coming new to the system have to hold in their head - if I know that you serve n resources, each of which has 4 well understood verbs, it's much easier to reason about than if I must know the verbs which go with each object and what they do to that particular object in your world. Of course the real world and real systems will never conform to this sort of system, and you have to break out of it occasionally, but sometimes it's a good starting point as long as you're don't let it limit the horizons of your world, such that only 4 verbs should be enough for anyone, or verbs become completely subsidiary to nouns and must be escorted by them at all times. Zealotry based on this perfectly reasonable idea (limiting complexity to promote understanding) often leads to a Kingdom of Nouns situation: http://steve-yegge.blogspot.co.uk/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.co.uk/2006/03/execution-in-kingd...