3 ms·

I have yet to see a crystal clear definition of REST. Where would be the best one you have found?

by BenoitP 13y ago

kordless 13y ago
It's a style, not an implementation. Highly opinionated definitions are the norm for REST.
- protonfish 13y ago
  It is defined very clearly. The fact that most developers don't know what it is does not mean REST is a subjective style.
ChikkaChiChi 13y ago
For the sake of brevity and callback, I'll say it's a SMART wrapper over a backend service or services (commonly at this point, a relational database).
protonfish 13y ago
I think the best definition is in Fielding's thesis where he lists the 4 REST interface constraints: 1) Identification of resources 2) Manipulations through representations 3) Self-descriptive messages and 4) HATEOAS. 1 & 2 mean that you should name a resource something for identification only and that name should be used no matter what you are doing to it. In HTTP you use a combination of verbs and request body data to tell the server what to do with a resource. HTTP implements #3 though status codes including verbose descriptions in the response body. HATEOAS (Hypermedia as the engine of application state) means that 100% of functionality must be accessible through a browser.
scott_w 13y ago
REST is a set of constraints for building a system. A RESTful interface is one that cleanly abstracts the underlying data store into one that is simple to use for third party systems. It's important to understand that a RESTful system doesn't necessarily expose a true model of the underlying data store. You could have an invoicing system that contains Customer and Invoice models. I see developers confusing that to mean "you have /customer/ and /invoice/ endpoints and never the twain shall meet". If you need to embed customer details into invoices and/or invoice details into customers, then feel free to do that if it makes sense for your application. There's more to it than that, and I've mostly just described how common HTTP-based RESTful systems work. Fielding gave a lot more detail in his thesis: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... I'd recommend reading it, as it helps clarify a few things. Also read up on the term HATEOAS, which details how information should be interlinked where possible, so your system can be (theoretically) crawled for more information.

I have yet to see a crystal clear definition of REST. Where would be the best one you have found?

by BenoitP 13y ago

I have yet to see a crystal clear definition of REST. Where would be the best one you have found?

kordless 13y ago

It's a style, not an implementation. Highly opinionated definitions are the norm for REST.

protonfish 13y ago
It is defined very clearly. The fact that most developers don't know what it is does not mean REST is a subjective style.

ChikkaChiChi 13y ago

For the sake of brevity and callback, I'll say it's a SMART wrapper over a backend service or services (commonly at this point, a relational database).

protonfish 13y ago

I think the best definition is in Fielding's thesis where he lists the 4 REST interface constraints: 1) Identification of resources 2) Manipulations through representations 3) Self-descriptive messages and 4) HATEOAS. 1 & 2 mean that you should name a resource something for identification only and that name should be used no matter what you are doing to it. In HTTP you use a combination of verbs and request body data to tell the server what to do with a resource. HTTP implements #3 though status codes including verbose descriptions in the response body. HATEOAS (Hypermedia as the engine of application state) means that 100% of functionality must be accessible through a browser.

scott_w 13y ago

REST is a set of constraints for building a system. A RESTful interface is one that cleanly abstracts the underlying data store into one that is simple to use for third party systems. It's important to understand that a RESTful system doesn't necessarily expose a true model of the underlying data store. You could have an invoicing system that contains Customer and Invoice models. I see developers confusing that to mean "you have /customer/ and /invoice/ endpoints and never the twain shall meet". If you need to embed customer details into invoices and/or invoice details into customers, then feel free to do that if it makes sense for your application. There's more to it than that, and I've mostly just described how common HTTP-based RESTful systems work. Fielding gave a lot more detail in his thesis: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... I'd recommend reading it, as it helps clarify a few things. Also read up on the term HATEOAS, which details how information should be interlinked where possible, so your system can be (theoretically) crawled for more information.