CODEWITHSUNDEEP
xmljsonrestsoap
Joe Boehm
Joe Boehm

Reputation: 1

Explain the "resource" in REST

Help me understand the importance of resource orientation with REST. Section 5.2.1.1 of the Fielding dissertation says "The key abstraction of information in REST is a resource." I've always thought this implied a resource orientation to REST services. I have a resources like a driver, or vehicle, or account. I can interact with this resource by a URI, and the nature of my interaction is described by the HTTP verb. POST for create, PUT for update etc.

If someone comes to me with a design for a REST service called something like "updateAddress", my instinct is to say that it is not REST. It has a verb in its name. A resource ought to named with a noun. You could implement a system that allows consumers to invoke a updateAddress operation by plain-old-XML over HTTP, and it would work just fine. But its not REST. To be REST, the resource should be "address". You can create, update, retrieve, and delete it, using POST, PUT, GET, and DELETE.

So long as all the interactions that are needed for you application are CRUD, my conception of REST works fine. But not everything is CRUD, and that's where I stumble on the whole concept. If I I have a "transfer funds" use case, how do I do it? With a single call, I want to change the state of two resources, account1, and account2. Do I make this a PUT to the resource that represents account1, and make account2 a parameter? Do I expect my consumer to make a PUT to both account resources? Do I construe my transaction into a noun, something like "FundTranser", and ask my consumer to POST that?

What about the fact that for many objects in the business domain there are different kinds of updates that occur? If I have 25 different use cases where I update different aspects of ACCOUNT, am I really expected to accomplish all of those with PUTs to the ACCOUNT resource?

My experience has bee that most people just ignore this. They design an operation with a verb in its name, just like they would do if they were designing a SOAP service operation. That operation name becomes the root element in the body of their message. And they use POST for everything. Even the "deleteAccount" and "retrieveAccount" operations are POST.

In the minds of most people, the term REST has come to mean "Not SOAP". Any plain-old-XML over HTTP is REST in their mind.

My question for all of you is, at the end of the day, does it matter? If I argue with them that their design is not "real REST", am I just hanging on to an academic point? Is there anything lost by doing POX over HTTP? Is there any harm in calling it REST?

Upvotes: 0

Views: 66

Answers (1)

inf3rno
inf3rno

Reputation: 26129

So long as all the interactions that are needed for you application are CRUD, my conception of REST works fine. But not everything is CRUD, and that's where I stumble on the whole concept.

You have more methods, not just CRUD. For example PATCH. So REST is not CRUD. You can always define a new resource which describes what you want.

If I I have a "transfer funds" use case, how do I do it? With a single call, I want to change the state of two resources, account1, and account2. Do I make this a PUT to the resource that represents account1, and make account2 a parameter? Do I expect my consumer to make a PUT to both account resources? Do I construe my transaction into a noun, something like "FundTranser", and ask my consumer to POST that?

In this case you are creating something new: a transfer, so yes, you should use POST /fundtransfers/, or something like that.

If I have 25 different use cases where I update different aspects of ACCOUNT, am I really expected to accomplish all of those with PUTs to the ACCOUNT resource?

You can use PATCH for partial updates or you can define sub-resources and use PUT on them.

  • PATCH /account {name: "..."}
  • PATCH /account/name "..."

My experience has bee that most people just ignore this.

Yes, and they don't develop REST services. They just claim that they are, because calling everything as REST is a hype.

Is there any harm in calling it REST?

Ofc. it is. You are confused because it, and most of the beginners feel the same. I think everybody who wants to work with REST have to read the Fielding dissertation first.

Btw, the words REST and RESTful are exhausted by ppl who not care. So nowadays we use the terms web API and hypermedia API to distinguish web services which violate REST constraints from the rare ones which fulfill.

Upvotes: 1

Related Questions