- Details
- Written by: Stanko Milosev
- Category: REST
- Hits: 6143
Here is what I read from the RemObjects news group:
Note that REST isn't a standard, nor does it define any metadata format. The only thing REST specifies is that you use GET to retrieve data, POST to save it, PUT to insert it and DELETE to delete it. Besides that there's nothing that is specified at all.
---
Due to the lack of metadata or standardization for REST, this is a very complex subject.
--
Carlo Kok
We've been looking at a REST interface. As Carlo mentioned there is little in the way of standards and everyone seems ti implement their own. One of the simplest we've seen basically has the format
http://mysite.com/rest?method=MethodName&apikey=KeyValue&ArgName1=xyz&ArgName2=123
we've decided that the simplest way to implement this is through a standrad webbroker app which then links to a RO server.
The rest handling method, looks at the method name and calls this on the server, bit of a manual job at the moment but we are looking on at least creating an app to creat the code if you see what I mean.
The apikey is there to ensure that only valid users access the app.
--
Russell Weetch
- Details
- Written by: Stanko Milosev
- Category: REST
- Hits: 5834
Representational State Transfer
History
- REST is architectural style developed in parallel to the HTTP/1.1 protocol
- The largest known implementation of a system conforming to the REST architectural style is the Web
- It is possible to design a software system in accordance with Fielding's REST architectural style without using HTTP and without interacting with the World Wide Web
REST in short
- REST is more like style of programming
- Best example of REST is RSS
- REST is KISS
- Why Representational State Transfer?
- If user go to www.milosev.com
- he will get the web page (Representational)
- browser will change his page (State)
- if user click on a link he will change (Transfer) browser state
Concept
- Consists of clients and servers
- It doesn't use resources on a network or server
- example: web page, user can use web page, without sending messages to the server
- Client sends messaged to the server only when it goes to new state
Constraints
- Client - server
- clients are not concerned with data storage
- servers are not concerned with the user interface or user state
- Stateless
- each request from any client contains all of the information necessary to service the request, and any state is held in the client
- Cacheable
- well-managed caching partially and completely eliminates some client-server interactions, further improving scalability and performance
- Uniform interface
- simplifies and decouples the architecture
- principles:
- individual resources are identified in requests
- manipulation of resources through these representations
- self descriptive messages
- hypermedia as the engine of application state
- Layered system
- a client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way
- Code on demand (optional)
- Servers are able to transfer logic to the client that it can execute (example: JavaScript)
Resources
- An important concept in REST is the existence of resources
- Client doesn't know is there cache, proxy, firewall, or anything else between client or server
- Client must know format of the information which is back
References
-
Wikipedia: http://en.wikipedia.org/wiki/Representational_State_Transfer
- Marco Cantu: http://blog.marcocantu.com/blog/soaprest.html
- xFront: http://www.xfront.com/REST-Web-Services.html