SitePoint Sponsor |
|
User Tag List
Results 26 to 50 of 117
Thread: REST opinions
-
May 4, 2004, 07:59 #26
- Join Date
- Mar 2004
- Location
- Netherlands
- Posts
- 138
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
Now I really don't understand. You would need frames or some such to maintain state as otherwise the whole thing will be blown away by the next request.
As I said, you can use cookies to maintain client state over multiple requests. The server should't touch the cookie though.
Also I thought REST was about not shipping app. code (like applets) to the browser, just document formats.
Now I know programs are just data, but it seems you are taking the complexity out of the server architecture and just moving the whole lot into a massively complex document.
I used to think that web applications should be implemented using static HTML and keeping all functionality on the server, so I can understand how you feel. It's quite a mindshift.
And please don't get me wrong: I will never say that it's easy to make such a seperation. It's in some way comparable to OO design; deciding which party does what.
-
May 4, 2004, 08:05 #27
- Join Date
- Mar 2004
- Location
- Netherlands
- Posts
- 138
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
The question is then what URL do you use to create a new article? Perhaps http://site.com/articles/new ? Almost a verb but not quite.
-
May 4, 2004, 08:14 #28
- Join Date
- Mar 2004
- Location
- Netherlands
- Posts
- 138
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Question - if a client can support many content types, how does it instruct the server what type it would prefer?
There's one problem that keeps coming up:
There are no browsers that support the powerful features of HTTP. It's the fault of the browser makers that we know have to develop our own solutions... with incompatible implementations.
This means that REST is better in theory than in practice. Lack of tool support...
-
May 4, 2004, 09:01 #29
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by sike
Post a note to the support forum as this is a bit off topic even for the original off topic strand.
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
May 4, 2004, 11:37 #30
Originally Posted by lastcraft
Sike
-
May 4, 2004, 12:18 #31
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by sike
yours, Marcus
p.s. Sorry Jeff. You can have your thread back now...Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
May 4, 2004, 13:37 #32
- Join Date
- Nov 2000
- Location
- Switzerland
- Posts
- 2,479
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
The follow up question is where do you place the HTML forms for making the POSTs, without using verbs? REST seems to suggest you have "documents" represented by URLs and "tools" for editing (and perhaps navigating) them.
Seems to me that REST is a pattern rather than some "one true way".
-
May 5, 2004, 04:58 #33
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by meryn
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
-
May 5, 2004, 07:21 #34
- Join Date
- Mar 2004
- Location
- Netherlands
- Posts
- 138
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
For example, say you wanted a PDF for better printing. There is no PDF filter button available on the browser, so it has to be taken as a preference into the server.
As I see it, the whole world has settled upon using only a subset of the features of HTTP. This won't change soon, if this changes ever. The main reason for this is that GET and POST, combined with sessions and complex URLs is 'good enough' in most cases.
I'm still hoping that sometime in the near future, an opensource project like mozilla or konquerer will make a browser that fully supports all HTTP 1.1 features, so you could use this as a platform to make advanced REST-based intranets (where you have control over the clients). It wouldn't exclude other browsers ofcourse. They at least would still be able to GET all available resources.
-
May 5, 2004, 07:37 #35
- Join Date
- Mar 2004
- Location
- Netherlands
- Posts
- 138
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
REST seems to suggest you have "documents" represented by URLs and "tools" for editing (and perhaps navigating) them.
The follow up question is where do you place the HTML forms for making the POSTs, without using verbs?
You could also decide to only show the add form when the articles resource is queried with ?action=add.
Another option would be to think of adding an article as a service, which in turn can be seen as a resource. GET /articles/addservice/ would return a form, and posting the form to the addservice would trigger the service to change the /articles/ resource. The interpretation of a resource can be as broad as you want...
-
May 6, 2004, 01:06 #36
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by meryn
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
-
Oct 3, 2004, 05:02 #37
- Join Date
- Oct 2004
- Location
- malaysia
- Posts
- 18
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
any real world REST implementation guides?
hi, i'm newbie in REST.. but really get interested about its idea.
i've been googling for REST tutorials and implementation guides recently, however i couldn't really find a nice complete article demonstrating a implementation of REST on current web app.
if anyone already using REST in web app., do share some ideas, thanx.
-----
btw, since REST is using HTTP basic methods (PUT, GET, DELETE, POST etc)
how well does PHP support HTTP /1.1 spec? will it be suitable to use PHP on writing a RESTful server?
i just get started coding with php. so, pls correct me if i'm wrong. Searching thru' php4 doc, i couldn't find a way to handle HTTP DELETE method.. and PUT is being handle quite 'differently' from GET and POST.
is there a better solution to handle HTTP methods via php?
-
Oct 3, 2004, 12:01 #38
- Join Date
- Mar 2004
- Location
- Netherlands
- Posts
- 138
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
The best example of a widely used RESTful application is the Atom API. It's used in blogging software. It also has a PHP implementation. It can be found at http://www.isolani.co.uk/blog/atom/P...Implementation .
The HTTP request method is available in $_SERVER['REQUEST_METHOD'].
For non-CRUD oriented applications (i.e. those involving complex business logic and processes) it takes quite a mindshift to explain this in terms of resources which can be read (GET), changed (PUT), DELETEd or POSTed to. I certainly found it a challenge, and it still is.
If you have specific questions RESTifying your application, you could best start a new thread I think. I might be able to help. I'll check these forums some more often from now on.
-
Oct 4, 2004, 05:44 #39
- Join Date
- Oct 2004
- Location
- malaysia
- Posts
- 18
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Thanx for the reference link about ATOM.
i've read about ATOM juz now. tat's really a good start point to learn about REST design.
i think one thing that most non-CRUD web application developer do concern is the user-session management, which already widely deployed in current web-based business.
well, i think i'll just start a new thread
-
Jul 20, 2005, 17:33 #40
- Join Date
- Oct 2004
- Location
- malaysia
- Posts
- 18
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
It has been a while, since the last post about REST discussion.
Yesterday, I made a simple presentation slide, by using Weblog as an
example of web applications, the slide will introduce to readers the basic
idea of how a RESTful web application looks like.
Wish to recieve your comments and suggestions about slide's contents
Here's the link: http://www.geocities.com/iamstupidio...ple-Weblog.ppt
(Please pm me if you have any access problem to that file).
-
Jul 21, 2005, 09:01 #41
- Join Date
- Jul 2004
- Location
- Gerodieville Central, UK
- Posts
- 446
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by stupidiot
-
Jul 21, 2005, 11:00 #42
- Join Date
- Nov 2001
- Location
- Bath, UK
- Posts
- 2,498
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
You don't want to have GET requests that modify things serverside, example: Google releases Web Accelerator, which pre-downloads pages that it sees links to. People visit pages with links to delete content, content gets deleted. Bad bad bad.
I don't believe IE supports PUT and DELETE, which puts a bit of a damper on things. That's why you only ever see GET and POST in the wild. You can simulate PUT and DELETE with POST, so all is cool. Add an <input type="hidden" name="method" value="DELETE" /> to your POST form and be happy.
You can get near-REST, but it means putting more things in cookies, unless you can argue sessions as a layer between the client and your RESTful app.
DouglasHello World
-
Jul 21, 2005, 14:13 #43
- Join Date
- Jun 2003
- Location
- Melbourne, Australia
- Posts
- 440
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by DougBTX
Can one force a browser to issue a PUT or a DELETE (by simple markup)?
Anyway, I found this project, previously mentioned by Harry interesting..Zealotry is contingent upon 100 posts and addiction 200?
-
Jul 22, 2005, 06:08 #44
- Join Date
- Oct 2004
- Location
- malaysia
- Posts
- 18
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by MiiJaySung
I think when we design a system, starting by identify required resources (which are all nouns), will effectively reduce cases, where "verbs" appear in URLs.
Originally Posted by MiiJaySung
Machines across Internet network understand HTTP methods well, and you can tell machines how to handle each type of request:
Code:DELETE /articles/23444 HTTP/1.1
Code:GET /articles/23444?action=delete HTTP/1.1 GET /delete.php?article=23444 HTTP/1.1
Real life truth...
Current browsers, and HTML specs only help us to send out GET and POST requests. Later browsers support XmlHttpRequest object to allow client scripts send out custom method request.
If we don't like forms and buttons in page design (me too :P), gmail is an example of using achor links to activate XmlHttpRequest objects using client scripts.
Some thoughts...
--------
I find that there're two ways to send out appropriate method requests using current browsers:
1. Clientscript - XmlHttpRequest + Forms
When the end user submits a form, XmlHttpRequest is called to send out the content with desired HTTP methods (GET,PUT,POST,DELETE etc).
The target URL should be referenced to the target resource itself.
2. POST + Forms
The forms act as a Processing Resource (as suggested by Mark Baker[BAKER]). When the end user pushes to submit button, content is POSTed to that form. The form will process and send out requests to target resources with appropriate HTTP methods.
The target URL should be referenced to that form.
Of course, GET is always easily available for everybody to retrieve our resources, by just providing a link. Two cases above are when we need to manipulate the resource state (or content).
Why we do that?
1. Clean separation client software and server software
Now, you can actually put your client software in different machines across Internet network. Changes in entire client codes, doesn't affect server software (which all resources stay).
2. Resources are more manageable
One resource is identified by one URL. If we want to prevent certain resource from being altered, we just block POST,PUT,DELETE requests and allow only GET request.
When resources grow more, we can migrate some of them to mirror server easily, and the old server will issue "3xx Redirect" response to inform clients.
[BAKER] An Abstract Model for HTTP Resource State (Section 3.1.4)
http://www.markbaker.ca/2001/09/draf...e-model-01.txt
-
Jul 22, 2005, 08:38 #45
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
unless you can argue sessions as a layer between the client and your RESTful app.
-
Jul 22, 2005, 09:58 #46
- Join Date
- Nov 2001
- Location
- Bath, UK
- Posts
- 2,498
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I think the idea behind REST is simply to keep all session data on the client, so keeping session data on the server isn't REST.
Then there are all the arguments about using HTTP as it was designed, which are all cool, but don't get too hung up on it if you don't have the browser support.
DouglasHello World
-
Jul 22, 2005, 12:07 #47
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Thanks for clearing that up for me. I had the suspision but just wasn't all that sure
-
Jul 22, 2005, 18:36 #48
- Join Date
- Jun 2003
- Location
- Melbourne, Australia
- Posts
- 440
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Dr Livingston
The problem is that a cookie is defined as being attached to any future requests for a given set of resource identifiers, usually encompassing an entire site, rather than being associated with the particular application state (the set of currently rendered representations) on the browser.
...snip...
Cookies also violate REST because they allow data to be passed without sufficiently identifying its semantics, thus becoming a concern for both security and privacy. The combination of cookies with the Referer [sic] header field makes it possible to track a user as they browse between sites.
Originally Posted by stupidiot
The same functionality should have been accomplished via anonymous authentication and true client-side state. A state mechanism that involves preferences can be more efficiently implemented using judicious use of context-setting URI rather than cookies, where judicious means one URI per state rather than an unbounded number of URI due to the embedding of a user-id.Zealotry is contingent upon 100 posts and addiction 200?
-
Jul 23, 2005, 02:03 #49
- Join Date
- Oct 2004
- Location
- malaysia
- Posts
- 18
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by auricle
-
Jul 23, 2005, 19:06 #50
- Join Date
- Jun 2003
- Location
- Melbourne, Australia
- Posts
- 440
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by stupidiot
Zealotry is contingent upon 100 posts and addiction 200?
Bookmarks