ReST

Representational State Transfer. A model for resource interaction that scales like the World Wide Web - is Generative - so even if designing an Enterprise architecture you get more scalability and flexibility.

• Representation: a Resource (identified by URI) can have multiple representations (XML, HTML, JSON, RSS, etc.)

• a CRUD Update is requesting a Resource to change its State (State Machine)

  • many interactions are more complex than a CRUD, but are still a State change. ReST components perform actions on a resource by using a representation to capture the current or intended state of that resource and transferring that representation between components.

    • 2008-07-27-DehoraPatternsWebArchitecture little bit

    • 2006-07-01-DhhWorldOfCrud

    • 2006-11-17-RestVsSoapAgain

    • 2007-01-12-DowneyWebsiteApi maybe

Richardson Maturity Model - Leonard Richardson

• Mar'2010: Martin Fowler comments

• May'2011: Duncan Cragg comments. Among other things: *So don't get stressed out about just using HttpPost - as long as you're being Declarative and not tunnelling Imperative function calls:

  • Use POST the way the Web does: to return whole data structures in an agreed, stable domain-specific format over a common base Media Type
  • Use POST the way the Web should have done: idempotently! Which means putting enough identifying information in the content so that you can tell if you've seen it already
  • POST to real, HttpGet-able resources .. and don't forget to invalidate the cache of that resource as the POST flies by*

Restful Web Services by Leonard Richardson and Sam Ruby

http://www.infoq.com/articles/rest-anti-patterns

http://www.xml.com/pub/a/2002/02/06/rest.html

http://rest.blueoxen.net/cgi-bin/wiki.pl?FrontPage

http://www.xfront.com/ReST-Web-Services.html

excellent explanation of the value/simplicity of ReST and HTTP.

the FAQ includes some interesting notes on application of ReST approach to things you wouldn't normally associate HTTP with - e.g. Instant Messaging, and compares it to SOAP.

2015: http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api

one key concept is that each schema stays focused on just describing some data - then when add different functions/requirements, you just pass that data to a new URI associated with that transaction. That smells like a nice thing...

http://www.soundadvice.id.au/blog/2006/09/29/#commonRESTQuestions

Documenting ReST API

• multiple Meta Data format approaches
  • see esp Swagger https://helloreverb.com/developers/swagger
  • see also HATEOAS

Python Web Framework- and ReST

Sept'2015 http://www.fullstackpython.com/api-creation.html

and AJAX http://www.onlamp.com/pub/a/python/2006/02/23/using-rest-with-ajax.html

Joe Gregorio, example URI-s http://www.xml.com/pub/a/2005/08/17/restful-web.html

Quixote http://www.rexx.com/~dkuhlman/rest_howto.html

Zope support <http://www.vanpyz.org/conference/2006/proceedings/8rMJUi/Rest Zope.html>

ROCA: Resource Oriented Client Architecture