Hacker News new | ask | show | jobs
by bodhi 4425 days 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?

1 comments

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.

> 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?

Well, you have a noun "donation". Whether it has multiple or single verbs depends on what operations make sense against that noun. Though it seems like that it would support multiple verbs.

There is no guarantee in REST that an operation on one resource has no effect on other resources. In fact, its quite common for operations to effect other resources.

> 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.

The method is that in this case, the "donation" resources would support appropriate verbs, and the other nouns which could not be changed independently which might be changed as a result of actions on the donation resource would not need verbs to support those changes, but would change as a result of the course of implementing the actions on the donation resource.

People seem to think of REST in terms of mapping to RDBMSs with resources as analogous records in base tables in a normalized schema against which you conduct CRUD operations. But, if you have to think of REST in RDBMS terms, its a better analogy to think of the resources exposed by an API as records in a set of potentially updatable, potentially denormalized, and potentially overlapping views rather than base tables.

> 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.