"piers_lawson" wrote:
>
> Could you post a small sample showing what you mean exactly. So a
> feed that contains one (or even better two feeds)... and for the
> parent feed and the child feeds they contain some additional data
> beyond the standard fields supportted by Atom. I think an example
> would really solidify it in my mind.
>
I'm working on your example. The demo I posted shows what I'm talking
about, but I haven't worked the rest of my solution into the demo yet.
When I have, I'll bump here. I'm almost finished (I think) making the
XSLT also function in Opera (using a holistic approach to the cross-
browser XSLT problem, rather than using @mode and an engine test, i.e.
making some code specific to Mozilla's Transformiix processor or Opera's
libxslt).
After I've made the XSLT work with WebKit, I'll work those other tricks
up my sleeve for dealing with collections into the demo. Then I'll make
the XSLT work with IE, so I can get back to my original problem, which
is dealing with Xforms. IE has a couple of nice Xforms extensions
available.
The result of this work, for me, will be a development style based on
the union of subsets of XSLT 1.0, EXSLT and Xforms that works on the
Web. And, a coding style (which can be validated using RELAX NG +
Schematron) for hitting that cross-browser sweet spot, which results in
code that also works for server-side transformation (if nothing else
works, libxslt can be used on the server).
Anyway, I ought to be able to provide an interesting collection example
for you later this week.
-Eric
The default httpd response is the domain parking page, which you can
see in action here:
http://way.groo.vi/
Nanoweb has lots of cool stuff that I'm trying not to break, and some
solid ideas for httpd implementation, including an .nwaccess format
that's bass-ackwards from .htaccess but which I prefer.
-Eric
>
> Feedback coming in... just a few clicking around (safari) and noticed
> content "negotiation" through URI template:
> http://charger.bisonsystems.net/xmltest/2006/aug/09/11.axml (also a
> 404 here)
>
Yeah, that stuff isn't built yet. I had to get creative with filename
extensions, but that's a contrivance of the demo.
-Eric
On Sat, Feb 6, 2010 at 8:33 PM, Eric J. Bowman <eric@...> wrote:
OK, it's rough around the edges yet, but it's time I posted it. There
are a few ways in. If you're interested in the httpd project, start
here, any browser will do:
Yeah, there's a button to push. Sorry, I'm working on Xforms capability
in an unobtrusive fashion, but development of same is required to be
obtrusive.
Normally, I restrict all the internals stuff to localhost access, but
for this demo I've created the charger-admin alias. Don't worry, the
whole thing is read-only, so you can't do any damage. (I hope... :-)
The purpose is to demo a whole buncha stuff. The only links that work
(apart from the directory browser) are the ones in body content, and
the 'View' menu (the button for which takes you back into the directory
browser, btw), but the variants are under construction so there's
nothing to see there at this time.
Drilling down to individual posts, comment threads, and standalone
comments does work. And, all from one XSLT stylesheet. That's the
part where the application logic and XHTML template are cached on the
client, and based entirely on standard elements and link relations.
The applicability of this, of course, goes far beyond the demo's nature
as a weblog.
Sandbox API is next, after the /date service is finished (a simple REST
service to transform ISO 8601 date strings into human-readable form).
All further notes are there in the project. Q&A taken here, on-topic
to the RESTful nature of the design (and proposed design, as described
by the Accept and Allow headers). I haven't figured out what I want to
do with OPTIONS on this project, yet.
OK, it's rough around the edges yet, but it's time I posted it. There
are a few ways in. If you're interested in the httpd project, start
here, any browser will do:
http://charger.bisonsystems.net/http://charger-admin.bisonsystems.net/
Or, you can jump into the project directly, but compatibility is
currently limited to Firefox:
http://charger.bisonsystems.net/xmltest/index.xht
Yeah, there's a button to push. Sorry, I'm working on Xforms capability
in an unobtrusive fashion, but development of same is required to be
obtrusive.
Normally, I restrict all the internals stuff to localhost access, but
for this demo I've created the charger-admin alias. Don't worry, the
whole thing is read-only, so you can't do any damage. (I hope... :-)
The purpose is to demo a whole buncha stuff. The only links that work
(apart from the directory browser) are the ones in body content, and
the 'View' menu (the button for which takes you back into the directory
browser, btw), but the variants are under construction so there's
nothing to see there at this time.
Drilling down to individual posts, comment threads, and standalone
comments does work. And, all from one XSLT stylesheet. That's the
part where the application logic and XHTML template are cached on the
client, and based entirely on standard elements and link relations.
The applicability of this, of course, goes far beyond the demo's nature
as a weblog.
Sandbox API is next, after the /date service is finished (a simple REST
service to transform ISO 8601 date strings into human-readable form).
All further notes are there in the project. Q&A taken here, on-topic
to the RESTful nature of the design (and proposed design, as described
by the Accept and Allow headers). I haven't figured out what I want to
do with OPTIONS on this project, yet.
-Eric
Thanks Eric,
Could you post a small sample showing what you mean exactly. So a feed that
contains one (or even better two feeds)... and for the parent feed and the child
feeds they contain some additional data beyond the standard fields supportted by
Atom. I think an example would really solidify it in my mind.
Thank you for your input so far!
This wound up a long post, so I'm going to start by pre-stating that
HTTP is an application protocol, and by prepeating my summary as thesis:
Application steady states are derived from HTTP messaging (think of a
browser diplaying a default 'broken image' icon, a different steady-
state than one where the image was retrieved and rendered) separately
from the state (and media type) of the resource that provided the
container representation.
Andrew Wahbe wrote:
>
> Good point. One thing about PUT and DELETE is that, other than Atom,
> there aren't a lot (any?) good examples of how to use them in
> hypermedia. AFAIK, HTML5 is just saying to add them as an option on
> <form> which is a bit silly
>
Last I checked, adding Xforms to HTML 5 was still under active
consideration. I don't consider Atom a good example of using PUT and
DELETE in hypermedia, because the hypermedia isn't actually instructing
the client what to do. I have mentioned my Xforms Atom Protocol
client, coming soon to a demo near you...
My initial posting of the demo won't include a nifty Xforms interface,
though. The pragmatic reason for distilling out a static demo from my
ongoing project, is to fully explore the notion of Xforms client
implementation -- Xforms relies on XHTML or SVG as a host language, so
it's a matter of client capability that isn't exposed in headers,
meaning you can't conneg around the problem, so I'm kinda stuck...
The demo will also (eventually) have a sandbox for publishing text/plain
files (until it gets spammed, anyway) that y'all can play with, which
allows for PUT and DELETE. Obviously, text/plain isn't a media type
which describes PUT and DELETE, but the interface is Xforms, which adds
support for those methods into the host-language media type -- the
media types of the host language and the target don't matter to my
sandbox API, so long as Xforms is allowed by the host language...
The directory contents will be modeled as XBEL, using application/xbel
+xml, and served (like the rest of the demo) using client-side XSLT to
turn that into XHTML + Xforms. The sandbox API, unlike Atom Protocol,
is RESTful and does it without minting any media (sub)types, by using an
existing media type already defined for collections of URIs of any media
type...
If logged in using HTTP Digest, the username is used as the port 80
process ID (group 'user' not 'www'). File creation is handled via POST
to the collection, as with Atom Protocol. Users may only DELETE files
they have created, but may edit (PUT) files created by others, based on
the standard UNIX file and directory permissions already constraining
the behavior of the httpd.
The "sandbox API" is what I've been using for years to update .xsl, .css
and .js files on my previous demos (without the newly-added hypertext
constraint). If I need to close the sandbox, I just 'chmod -w sandbox',
or make the server 410 with '-r' (at directory or file level). Allowing
curl to PUT and DELETE is easy on an httpd, making it REST requires a
couple of extra steps, though. It's pretty cool, but I promise to stop
fiddling with it and post my demo without...
You can, of course, utilize the sandbox without the Xforms interface
(this 'paleowiki' is even fun to use with curl). But, in terms of
"learning the API" you can see it plain as day in the server-generated
hypertext application that self-documents it, and by introspecting
response codes with a protocol analyzer. So g'head (soon) and write a
quickie sandbox API client using libcurl, or just play with it using
curl. I don't care if you don't follow my provided hypertext, just
that I've met REST's burden of providing it, so you can figure out how
to use curl by using 'view source'.
>
> -- there doesn't seem to be any sense in a single hypertext construct
> being used for GET, POST, PUT and DELETE. The use cases and
> application flows for the different methods are just so different.
>
I agree; it's the immediate drawback I notice in:
http://www.w3.org/2007/03/html-forms/
Which I'm going to give a whirl, anyway. I prefer the raw Xforms MVC
design pattern. I have nothing against MVC per se, only its all-too-
common usage on the Web in systems which break the identification of
resources constraint. Putting MVC on the client makes it a RESTful
design pattern. The 'XRX' design pattern mates an Xforms frontend to
an Xquery backend; this design pattern may easily be implemented as a
decoupled REST system.
I can't get enough of that buzz I get writing Xforms applications for
RESTful systems -- the ability to rapidly prototype Web systems for
visualization and analysis, without using Javascript, blows me away. If
only I could figure out how to serve my Xforms applications to generic
clients, say by having Xforms included within HTML 5, I'd be thrilled...
>
> Let's consider Atom as an example here (as that's all we've got). If
> your client is reading a feed and decides to delete an entry and gets
> a 204 back, does the client have to GET the feed again before it can
> take any other actions on the feed? Or can it assume that the DELETE
> operation had the consequences outlined by HTTP, AtomPub and the edit
> relation and make an assumption about the current state of the feed?
>
Yes (sorta), and no. A client can't assume a 2xx response to mean
'success' because of 202. If the server has no intention of performing
the DELETE, then it should use a 4xx response. OTOH, a server isn't
beholden to its own 2xx response to a DELETE, so "caveat client"
applies. This goes for any media type, not just Atom, btw.
The server's response to a DELETE request is only the server's response
to the request (a shadow in Plato's cave). The effect on the resource
(the true form) can only be determined via subsequent request. Most
servers will change their response to 404, when the correct response is
usually a 410. But, even that depends on the context of the DELETE
request...
What if the DELETE request had a Link header whose link relation and
content describe the proper forwarding for the resource? If the
deleted resource has been combined with another, then a 307 redirect is
called for. However, if the resource has been moved to a new location,
the response would be a 301 redirect. Even if the client has no
control over this, the response code to the DELETE request itself, isn't
authoritative of much.
>
> In other words: maybe 204 doesn't mean "the steady state hasn't
> changed" but rather "the steady state has been adjusted as defined by
> the media type and the method"?
>
It means neither. It only informs the client that the DELETE request
didn't result in an error. Only the responses to GET, HEAD or OPTIONS
requests tell you anything about resource state. Any of these requests
made subsequent to a DELETE request will give a response code
indicating the state of the resource -- not found, gone, moved or
(perhaps) merged, etc. (Or, in the case of a collection feed, perhaps
all members were deleted, or just the collection, or both.)
REST "application state" is held entirely on the client. A REST system
has literally infinite "applications," defined as "what the user is
trying to do." The application presents the user with a representation
of resource state -- that's the first "steady state," when a form with a
delete button finishes loading and styling. That delete form allows
users to construct their own choice for the next state transition.
(Other possible state transition selections I'll ignore include, but
are not limited to: menu links, mailto links, links to help with the
form, etc. which may also appear as part of the form's steady-state.)
When a user hits the delete button, a DELETE request is sent to the
identified resource. Now, all heck breaks loose! We haven't a clue as
to the result of this action beyond "request accepted" or "request
rejected," which have nothing to do with resource state -- but
everything to do with *application* state.
What happens when the response is 4xx? There's no rule that says you
have to treat that 4xx response as the next application state (even
though you may do so). If you do, there's no reason the body of the
4xx response can't look identical to the last steady-state, although
you may want to add some text (or styling) indicating the failure. You
aren't limited to presenting your application within 200 responses.
If you don't want to load a new page, then Xforms can catch the response
code and restyle the page accordingly. For example, if the response
was 4xx, color the filename text red, gray it out, and make it not
selectable. There -- the application just transitioned to a new steady-
state without following any links (loading a new page). (The sandbox
API returns 202 Accepted to DELETE, does chmod -r and removes the file
from the XBEL index, causing a 410 response to subsequent requests --
who says my server has to allow you to delete your death threats...? ;-)
Likewise, if the response is 2xx, Xforms can turn right around and make
a HEAD request to the allegedly-deleted resource. If the response to
that is 4xx, the filename text is removed from the delete form's select
box (the sandbox API just reloads the XBEL file regardless of response).
There -- the application transitioned to a new steady-state without
following any links, again. HTTP is an application messaging protocol.
The URI which responded with the delete form, has that delete form as
its resource state. But, the client's application state varies based
on the state of each resource in the directory it represents in its
select box as a list of filenames (or the state of a linked XBEL-
represented index resource, in the sandbox API case -- the XBEL document
is the Xforms 'Model', so refreshing the model shows the outcome of the
DELETE request, which will be 304 on failure due to matching Etag).
So the state of such a delete application transitions from one steady-
state to another based on the user selecting a filename and clicking
the delete button -- regardless of whether your delete form is updating
dynamically, or you are using it as a representation of the success and
failure states expressed in response to the DELETE (by following the
link, i.e. loading a new 4xx response page, dereferencing the deleted
URL, whatevah), or media type used (I've given a general idea on how
this is done, plus specifics of how it's done in my forthcoming sandbox
API, without mentioning Atom).
About the only REST no-no with a 204 response, is to present the user
with that response as the next application state -- a blank page. So
the client needs to have some logic, i.e. make a HEAD request and
dynamically restyle, or make a GET request and present the user with a
"success" application state wrapped in a 4xx response (which breaks no
REST constraints -- resource state and application state aren't the
same thing).
In a nut, this behavior is out-of-scope to media type, it's all about
HTTP as application (not transport) protocol. Application steady
states are derived from HTTP messaging (think of a browser diplaying a
default 'broken image' icon, a different steady-state than one where
the image was retrieved and rendered) separately from the state of the
resource that provided the container representation.
</ramble_on>
Watching Pagey "Ramble On" on my "It Might Get Loud" DVD too much,
Eric
http://www.jfokus.se/jfokus/preso/jf-10_DomainDrivenRESTWeb-Services.pdf
thanks for all discussions here... every opinion influenced my under
progress work ..
Now I am designing and implementing the HATEOAS workflow engine....
let's see.....
* there are some terminology and conceptual abuse in my slides, but
live I commented out about that (like why application/xml is not
enough for rest, etc)...
--
------------------------------------------
Felipe Gaúcho
10+ Java Programmer
CEJUG Senior Advisor
On Wed, Feb 3, 2010 at 2:29 AM, Jan Algermissen <algermissen1971@...> wrote:
>
> So if you don't redirect then this leaves the client in either the steady state defined by the body or, if there was no body in the response, in the same steady state it was in before the request (sort of like a 204 response).
Yes. Interestingly, this means that the client's application state does not change although it made a request. But what if the client has this current state:
The client's state is now 'wrong' in the sense that the third link should be removed. Since the server cannot know what state the client was in before the DELETE request, it cannot really assist by sending the updated state.
Should the client take care of 'adjusting' the state itself?
On the contrary, if you did
POST /book/chapters/
<newCpater>
the server would usually say "Hey, this has updated some resource, look:"
303 See Other
Location: /book
Hmmm - so it is probably wise to do this then:
DELETE /book/appendix1.xml
303 See Other
Location: /book
Good point. One thing about PUT and DELETE is that, other than Atom, there aren't a lot (any?) good examples of how to use them in hypermedia. AFAIK, HTML5 is just saying to add them as an option on <form> which is a bit silly -- there doesn't seem to be any sense in a single hypertext construct being used for GET, POST, PUT and DELETE. The use cases and application flows for the different methods are just so different.
Let's consider Atom as an example here (as that's all we've got). If your client is reading a feed and decides to delete an entry and gets a 204 back, does the client have to GET the feed again before it can take any other actions on the feed? Or can it assume that the DELETE operation had the consequences outlined by HTTP, AtomPub and the edit relation and make an assumption about the current state of the feed?
In other words: maybe 204 doesn't mean "the steady state hasn't changed" but rather "the steady state has been adjusted as defined by the media type and the method"?
On Feb 3, 2010, at 5:56 AM, Andrew Wahbe wrote:
>
>
> Ok ya... very bad wording on my part. Not a violation of the spec -- more just
"disregard" for the spec. So "SHOULD" is to be treated as: "you really ought to
unless you really know what you are doing and you have a good, valid reason not
to", not "this is a good idea that you might want to consider". I find that most
folks seem to be omitting a body in 201 responses for no reason other than they
don't want to be bothered -- they are treating POST as being exempt to HATEOAS,
not even using the location header to redirect or anything like that. It's just
RPC with the procedure call returning a URI that happens to be in the location
header. Pet peeve of mine...
>
> Anyways, I've find the use of "Location" in 201 and 3xx to be a bit strange.
On the one hand, you'd think that the intent of using it in 201 is to redirect
the client to the new resource while indicating that a new resource has been
created. But I've never been able to find a definitive statement on whether 201
should result in a redirect. The only text that comes close is in the text
describing the location header itself:
> The Location response-header field is used to redirect the recipient
> to a location other than the Request-URI for completion of the
> request or identification of a new resource. For 201 (Created)
>
> responses, the Location is that of the new resource which was created
>
> by the request. For 3xx responses, the location SHOULD indicate the
> server's preferred URI for automatic redirection to the resource.
> It's not clear to me if the use of the word 'redirect' in the first sentence
means an automatic request here or not -- you'd think it would be more explicit
in the description of 201 if it was. I read it as to be used for automatic
redirection in the 3xx case and identification of the new resource in the 201
case. And AFAIK, no widely-used HTTP clients or browsers do auto-redirect on 201
I found this: http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i61 (which
suggests that the original intention was location of created resource OR
redirect target).
>
> So if you don't redirect then this leaves the client in either the steady
state defined by the body or, if there was no body in the response, in the same
steady state it was in before the request (sort of like a 204 response).
Yes. Interestingly, this means that the client's application state does not
change although it made a request. But what if the client has this current
state:
GET /book
<documentIndex>
<chapter href="chapter1.xml"/>
<chapter href="chapter2.xml"/>
<appendix href="appendix1.xml"/>
<chapters href="chapters/"/>
</documentIndex>
and then it does
DELETE /book/appendix1.xml
204 No Content
The client's state is now 'wrong' in the sense that the third link should be
removed. Since the server cannot know what state the client was in before the
DELETE request, it cannot really assist by sending the updated state.
Should the client take care of 'adjusting' the state itself?
On the contrary, if you did
POST /book/chapters/
<newCpater>
the server would usually say "Hey, this has updated some resource, look:"
303 See Other
Location: /book
Hmmm - so it is probably wise to do this then:
DELETE /book/appendix1.xml
303 See Other
Location: /book
>
> That's my take anyways -- would love to know if anyone had authoritative info
on if 201 was supposed to redirect (and the body was means as a "backup" as in
the 3xx case).
See link above.
Jan
>
> Andrew
>
> 2010/2/2 António Mota <amsmota@...>
> But SHOULD is not SHALL, is a recommendation not a imposition... So not having
a body on a 201 could not be considered a violation of the spec... Wich indeed
turns things more complicated in determining what a steady-state should be...
>
>
> _________________________________________________
>
> Melhores cumprimentos / Beir beannacht / Best regards
>
> António Manuel dos Santos Mota
>
> http://card.ly/amsmota
> _________________________________________________
>
>
>
> 2010/2/2 wahbedahbe <andrew.wahbe@...>
>
>
>
>
> --- In rest-discuss@yahoogroups.com, Jan Algermissen <algermissen1971@...>
wrote:
> >
> > When a client sends a POST request and receives a 201 Created...
> >
> > a) is the POST response body the steady state
> >
> > b) is it implied by HTTP spec that the client will do a GET on the Location
and is that the steady state?
> >
> > c) is this up to the media type that contained the link to the
POST-accepting resource?
> >
> >
> >
> > For other return codes I think this:
> >
> > 200 Ok - steady state is the POST response
> > 202 Accepted - steady state is available at the link provided by the body of
the 202 response
> > 303 See Other - steady state is available ta resource that the Location
points to
> >
> > Jan
> >
>
> I think the HTTP spec is pretty clear that 201 responses SHOULD have a body
which constitutes your steady state.
> Section 9.5:
> If a resource has been created on the origin server, the response
> SHOULD be 201 (Created) and contain an entity which describes the
> status of the request and refers to the new resource, and a
> Location header (see section 14.30)
> Section 10.2.2:
> The newly created resource can be referenced by the URI(s)
> returned in the entity of the response, with the most specific URI
> for the resource given by a Location header field. The response
> SHOULD include an entity containing a list of resource
> characteristics and location(s) from which the user or user agent
> can choose the one most appropriate. The entity format is
> specified by the media type given in the Content-Type header field.
>
> I've always considered the Location header in 201 responses as information for
intermediaries rather than the driver of application state. But I know I'm in
the minority on that: a lot of people don't even have a body in their 201
responses (which to me is a violation of the spec).
> Regards,
>
> Andrew
>
>
>
>
>
> --
> Andrew Wahbe
>
>
>
-----------------------------------
Jan Algermissen, Consultant
NORD Software Consulting
Mail: algermissen@...
Blog: http://www.nordsc.com/blog/
Work: http://www.nordsc.com/
-----------------------------------
Andrew Wahbe wrote:
>
> Ok ya... very bad wording on my part. Not a violation of the spec --
> more just "disregard" for the spec. So "SHOULD" is to be treated as:
> "you really ought to unless you really know what you are doing and
> you have a good, valid reason not to", not "this is a good idea that
> you might want to consider". (...)
>
The thing is, HTTP isn't constrained to being used on the Web. So
there are plenty of things in there which, in the context of the Web,
become a "MUST" even though the spec says "SHOULD". For example, the
use of registered media types. If your context is intranet, then knock
yourself out disrespecting the SHOULD by creating new media types willy-
nilly.
If your context is the Web, then how is an intermediary to tell the
difference between one application/vnd.customers+xml and another? Such
a collision is likely on the Web, so consider the use of registered
media types a MUST. If your context is intranet, then g'head. These
SHOULD instead of MUST situations in the spec aren't loopholes.
Off the Web, I send Content-Location with 201 responses instead of
Location, 'cuz it makes more sense to _me_ that way... But, I haven't
read 2616bis lately (really need to quit putting that off, now), so I
can't really comment on the issue, beyond pointing out that the Web
turns a lot of HTTP's SHOULDs into MUSTs, for all intents and purposes.
-Eric
Ok ya... very bad wording on my part. Not a violation of the spec -- more just "disregard" for the spec. So "SHOULD" is to be treated as: "you really ought to unless you really know what you are doing and you have a good, valid reason not to", not "this is a good idea that you might want to consider". I find that most folks seem to be omitting a body in 201 responses for no reason other than they don't want to be bothered -- they are treating POST as being exempt to HATEOAS, not even using the location header to redirect or anything like that. It's just RPC with the procedure call returning a URI that happens to be in the location header. Pet peeve of mine...
Anyways, I've find the use of "Location" in 201 and 3xx to be a bit strange. On the one hand, you'd think that the intent of using it in 201 is to redirect the client to the new resource while indicating that a new resource has been created. But I've never been able to find a definitive statement on whether 201 should result in a redirect. The only text that comes close is in the text describing the location header itself:
The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource. For 201 (Created)
responses, the Location is that of the new resource which was created by the request. For 3xx responses, the location SHOULD indicate the server's preferred URI for automatic redirection to the resource.
It's not clear to me if the use of the word 'redirect' in the first sentence means an automatic request here or not -- you'd think it would be more explicit in the description of 201 if it was. I read it as to be used for automatic redirection in the 3xx case and identification of the new resource in the 201 case. And AFAIK, no widely-used HTTP clients or browsers do auto-redirect on 201
So if you don't redirect then this leaves the client in either the steady state defined by the body or, if there was no body in the response, in the same steady state it was in before the request (sort of like a 204 response).
That's my take anyways -- would love to know if anyone had authoritative info on if 201 was supposed to redirect (and the body was means as a "backup" as in the 3xx case).
But SHOULD is not SHALL, is a recommendation not a imposition... So not having a body on a 201 could not be considered a violation of the spec... Wich indeed turns things more complicated in determining what a steady-state should be...
_________________________________________________
Melhores cumprimentos / Beir beannacht / Best regards
--- In rest-discuss@yahoogroups.com, Jan Algermissen <algermissen1971@...> wrote:
>
> When a client sends a POST request and receives a 201 Created...
>
> a) is the POST response body the steady state
>
> b) is it implied by HTTP spec that the client will do a GET on the Location and is that the steady state?
>
> c) is this up to the media type that contained the link to the POST-accepting resource?
>
>
>
> For other return codes I think this:
>
> 200 Ok - steady state is the POST response
> 202 Accepted - steady state is available at the link provided by the body of the 202 response
> 303 See Other - steady state is available ta resource that the Location points to
>
> Jan
>
I think the HTTP spec is pretty clear that 201 responses SHOULD have a body which constitutes your steady state.
Section 9.5:
If a resource has been created on the origin server, the response
SHOULD be 201 (Created) and contain an entity which describes the
status of the request and refers to the new resource, and a
Location header (see section 14.30)
Section 10.2.2:
The newly created resource can be referenced by the URI(s)
returned in the entity of the response, with the most specific URI
for the resource given by a Location header field. The response
SHOULD include an entity containing a list of resource
characteristics and location(s) from which the user or user agent
can choose the one most appropriate. The entity format is
specified by the media type given in the Content-Type header field.
I've always considered the Location header in 201 responses as information for intermediaries rather than the driver of application state. But I know I'm in the minority on that: a lot of people don't even have a body in their 201 responses (which to me is a violation of the spec).
Regards,
"piers_lawson" wrote:
>
> You mention a feed of feed approach... would that be a <feed> element
> that represents the parent resource, which then contained an <entry>
> for each "collection"? With the <entry> containing a link to the feed
> for that child collection (and possibly also containing an <inline>
> to provide a high level view of the child feed's content)?
>
Yes. If the client wants to access a feed within a feed, it can follow
the link rel='related' instead of the link rel='self' of an entry in
the original feed. The link rel='self' just points to the first entry
in the sub-collection.
This is the first I've heard of <inline>, so I can't answer as to that.
-Eric
Thanks for the quick response Eric. I'm certainly not dismissing Atom yet and I
hope I'm learning a lot from it and this discussion.
You mention a feed of feed approach... would that be a <feed> element that
represents the parent resource, which then contained an <entry> for each
"collection"? With the <entry> containing a link to the feed for that child
collection (and possibly also containing an <inline> to provide a high level
view of the child feed's content)?
I think what I'm missing is some good examples of using Atom outside of the
basic scenario. So given a resource that has properties of its own, and perhaps
is linked to at least one possibly two collections of other resources... how
would you represent it? What XML would you envisage being returned when the
parent is requested?
Thanks everyone for your time!
Have you looked at the threading extensions for Atom?
http://www.ietf.org/rfc/rfc4685.txt
I'm not a big fan of the service document. As far as generic clients
go, I think they can infer the editability of a resource by the
presence of a link rel='edit' without needing to consult a service
document. The response to a PUT request is what's authoritative, not
any sort of service document. Allow headers work just as well to
provide a hint as to acceptable methods.
Where I do use a "service document" in an otherwise-Atom Protocol
system, I repurpose Google's XML sitemaps so I have a hierarchical
format, instead of using a root-level flat-file document to define a
hierarchy.
You can also have feeds of feeds in Atom, so I don't really understand
the disadvantage you're seeing. I didn't propose Atom as the magical
solution to your problem, merely as a way forward. Once you've
identified its actual shortcomings, you're free to abandon it, but it
will give you an awful lot of ideas on how to use link relations
properly. See it through, though, since it provides a useful guideline
on how to arrange and link collections.
You can use standard link relations, even if you use your own
vocabulary as a resource model. Better to use standard media types,
though.
-Eric
"piers_lawson" wrote:
>
> Mike, thank you for pointing out the draft inlining spec... it was
> interesting.
>
> Jan, I started off the thread suggesting a format similar to the one
> that you put forward as one of my alternatives. I have been convinced
> by the idea that really the collection should not contain Account
> elements but some sort of link. The inlining idea is good in that it
> formalises combining a link with some data from the target
> resource.... at least it would be if the spec had moved forward from
> being a draft ;-)
>
> However, what I'm really pushing for is an example of publishing a
> feed (or even feeds) within other content, for example within the
> seller element from my last post. If I end up with something similar
> to my last post (i.e. a seller element that contains a feed element)
> I'm back to a custom vocabulary... at which point I can't see the
> advantage of using Atom feeds... a generic client would never find
> the feeds in the first place (because my seller element doesn't look
> anything like a Service document)... Any thoughts?
>
Mike, thank you for pointing out the draft inlining spec... it was interesting.
Jan, I started off the thread suggesting a format similar to the one that you
put forward as one of my alternatives. I have been convinced by the idea that
really the collection should not contain Account elements but some sort of link.
The inlining idea is good in that it formalises combining a link with some data
from the target resource.... at least it would be if the spec had moved forward
from being a draft ;-)
However, what I'm really pushing for is an example of publishing a feed (or even
feeds) within other content, for example within the seller element from my last
post. If I end up with something similar to my last post (i.e. a seller element
that contains a feed element) I'm back to a custom vocabulary... at which point
I can't see the advantage of using Atom feeds... a generic client would never
find the feeds in the first place (because my seller element doesn't look
anything like a Service document)...
Any thoughts?
I'll give it a try. I though I could make it using REST approach, but it
seems it is not gonna be possible.
Let's read and see if a flash comes ;)
See you
On 02/02/2010 18:10, António Mota wrote:
> Well, basically yes, is for synchronizing devices, but can be extended
> to other things. For example, we use (among other things) the Alert
> messages to pass what is called Command&Control messages between two
> systems.
>
> Now this is quite incompatible with the idea of REST, because SyncML
> is based on Command Elements, it's not resource oriented. What you can
> do is to use SyncML as payloads of REST messages, like you'll do with
> any other media-type, and let the service implementations deal with
> the SyncML itself.
>
> But even if this doesn't apply to your scenario, reading the sepc MAY
> give you some good ideas...
>
> _________________________________________________
>
> Melhores cumprimentos / Beir beannacht / Best regards
>
> António Manuel dos Santos Mota
>
> http://card.ly/amsmota
> _________________________________________________
>
>
>
>
> 2010/2/2 George<george.news@...>:
>>
>> On 02/02/2010 14:31, António Mota wrote:
>>>
>>> I just read this on the diagonal, but it seems similar to what SyncML
>>> does, is that the case?
>>
>> SyncML seems to be used to syncronized devices' (mobiles, handhelds,..)
information, such as contacts,... My case is not such a thing, as the commands
are for instance RS232 commands to be sent to a local device.
>>
>> Thanks. Anyway I will read a little further SyncML (curiosity)
>>
>> See you
>>
>>
>>
>>>
>>> _________________________________________________
>>>
>>> Melhores cumprimentos / Beir beannacht / Best regards
>>>
>>> António Manuel dos Santos Mota
>>>
>>> http://card.ly/amsmota
>>> _________________________________________________
>>>
>>>
>>>
>>>
>>> 2010/2/2 George<george.news@...>:
>>>>
>>>> Boing... any idea?
>>>>
>>>> On 01/02/2010 10:28, George wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> Let's try to explain it a little further.
>>>>>
>>>>> On 01/02/2010 9:02, Jan Algermissen wrote:
>>>>> > George,
>>>>> >
>>>>> > On Jan 30, 2010, at 1:38 PM, George wrote:
>>>>> >
>>>>> >> Hi,
>>>>> >>
>>>>> >> I'm planning to develop a webservice, and I like to try the
RESTful
>>>>> >> architecture.
>>>>> >>
>>>>> >> The service is about downloading some data from the server to a
device
>>>>> >> attached on the local computer. The client need to retrieve the
command
>>>>> >> from the server and then send the response of the device to the
server
>>>>> >> to check its validity. Then the server says if it is ok or not.
>>>>> >
>>>>> > I think I do not understand what you are up to. Why does the client
>>>>> fetch the command for the device from the server?
>>>>>
>>>>> The system is foreseen to control a hardware device. The issue is that
>>>>> the device only accepts a subset of commands based on some cryptographic
>>>>> features.
>>>>>
>>>>> I don't want the command set and the cryptographic keys to be on the
>>>>> client, as this way I have to replicate the keys on every client and the
>>>>> security can be comprised.
>>>>>
>>>>> Each command is encrypted with different keys depending on the device it
>>>>> is directed to. So the issue is first is that the server needs to know
>>>>> the device as to open the session with the correct set of keys. After
>>>>> that, the client get the command (encripted and maced with server keys),
>>>>> this command is sent to the device who will response. The response has
>>>>> some crypto stuff that need to be check on the server. Then the client
>>>>> get an ACK or NACK depending on the correct answer from the device
>>>>> (whether the command is well executed or not, or whether the device owns
>>>>> the correct set of keys and it not a fake device).
>>>>>
>>>>> >
>>>>> >
>>>>> >
>>>>> >>
>>>>> >> Device client Server
>>>>> >> ----> Get command
>>>>> >> <-----<-----
>>>>> >>
>>>>> >> ----> ----> Response from device
>>>>> >> <----- Response from server indicating
>>>>> >> if it is ok or not the execution
>>>>> >>
>>>>> >> It would be like: client calls authenticate of device. then the
server
>>>>> >> sends the command to be sent to the device for authentication.
>>>>> >
>>>>> > HTTP authentication is orthogonal. Use one of the HTTP standard
>>>>> authentication solutions.
>>>>>
>>>>> Authentication is done based on the crypto protocol that I explained
above.
>>>>>
>>>>> >
>>>>> >
>>>>> >> The
>>>>> >> client send this command to the device and the response is sent
back to
>>>>> >> the server. The server then replies.
>>>>> >>
>>>>> >> I have thought on:
>>>>> >> /device/{id} as resource
>>>>> >> /device/{id}/authenticate
>>>>> >> GET will retrieve the command and blank state
>>>>> >> <command> value</command>
>>>>> >> <state> not defined</command>
>>>>> >> PUT will send the response and get the real state
>>>>> >> ---> <response> value</response>
>>>>> >> <---<state> not defined</command>
>>>>> >>
>>>>> >> I don't know if this is REST. Is it better to create another
>>>>> resource as:
>>>>> >> /device/{id}/authenticate/command (only GET available)
>>>>> >> /device/{id}/authenticate/response (only PUT available)
>>>>> >> /device/{id}/authenticate (only GET avaliable for status)
>>>>> >>
>>>>> >> Any help is welcome.
>>>>> >
>>>>> > Can you explain your requirements? I am having trouble
understanding
>>>>> what you are trying to do.
>>>>>
>>>>> The issue is that I need to get a command and then check the answer from
>>>>> that command. This will be done in 2 steps, and I don't know how to map
>>>>> that into resources.
>>>>>
>>>>> Thanks... hope now is clearer.
>>>>>
>>>>> CU
>>>>> Jorge
>>>>>
>>>>> > Jan
>>>>> >
>>>>> >
>>>>> >
>>>>> >> TA
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> ------------------------------------
>>>>> >>
>>>>> >> Yahoo! Groups Links
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >
>>>>> > -----------------------------------
>>>>> > Jan Algermissen, Consultant
>>>>> >
>>>>> > Mail: algermissen@...<mailto:algermissen%40acm.org>
>>>>> > Blog: http://www.nordsc.com/blog/<http://www.nordsc.com/blog/>
>>>>> > Work: http://www.nordsc.com/<http://www.nordsc.com/>
>>>>> > -----------------------------------
>>>>> >
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------
>>>>
>>>> Yahoo! Groups Links
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
Well, basically yes, is for synchronizing devices, but can be extended
to other things. For example, we use (among other things) the Alert
messages to pass what is called Command&Control messages between two
systems.
Now this is quite incompatible with the idea of REST, because SyncML
is based on Command Elements, it's not resource oriented. What you can
do is to use SyncML as payloads of REST messages, like you'll do with
any other media-type, and let the service implementations deal with
the SyncML itself.
But even if this doesn't apply to your scenario, reading the sepc MAY
give you some good ideas...
_________________________________________________
Melhores cumprimentos / Beir beannacht / Best regards
António Manuel dos Santos Mota
http://card.ly/amsmota
_________________________________________________
2010/2/2 George <george.news@...>:
>
> On 02/02/2010 14:31, António Mota wrote:
>>
>> I just read this on the diagonal, but it seems similar to what SyncML
>> does, is that the case?
>
> SyncML seems to be used to syncronized devices' (mobiles, handhelds,..)
information, such as contacts,... My case is not such a thing, as the commands
are for instance RS232 commands to be sent to a local device.
>
> Thanks. Anyway I will read a little further SyncML (curiosity)
>
> See you
>
>
>
>>
>> _________________________________________________
>>
>> Melhores cumprimentos / Beir beannacht / Best regards
>>
>> António Manuel dos Santos Mota
>>
>> http://card.ly/amsmota
>> _________________________________________________
>>
>>
>>
>>
>> 2010/2/2 George<george.news@...>:
>>>
>>> Boing... any idea?
>>>
>>> On 01/02/2010 10:28, George wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> Let's try to explain it a little further.
>>>>
>>>> On 01/02/2010 9:02, Jan Algermissen wrote:
>>>> > George,
>>>> >
>>>> > On Jan 30, 2010, at 1:38 PM, George wrote:
>>>> >
>>>> >> Hi,
>>>> >>
>>>> >> I'm planning to develop a webservice, and I like to try the RESTful
>>>> >> architecture.
>>>> >>
>>>> >> The service is about downloading some data from the server to a device
>>>> >> attached on the local computer. The client need to retrieve the
command
>>>> >> from the server and then send the response of the device to the server
>>>> >> to check its validity. Then the server says if it is ok or not.
>>>> >
>>>> > I think I do not understand what you are up to. Why does the client
>>>> fetch the command for the device from the server?
>>>>
>>>> The system is foreseen to control a hardware device. The issue is that
>>>> the device only accepts a subset of commands based on some cryptographic
>>>> features.
>>>>
>>>> I don't want the command set and the cryptographic keys to be on the
>>>> client, as this way I have to replicate the keys on every client and the
>>>> security can be comprised.
>>>>
>>>> Each command is encrypted with different keys depending on the device it
>>>> is directed to. So the issue is first is that the server needs to know
>>>> the device as to open the session with the correct set of keys. After
>>>> that, the client get the command (encripted and maced with server keys),
>>>> this command is sent to the device who will response. The response has
>>>> some crypto stuff that need to be check on the server. Then the client
>>>> get an ACK or NACK depending on the correct answer from the device
>>>> (whether the command is well executed or not, or whether the device owns
>>>> the correct set of keys and it not a fake device).
>>>>
>>>> >
>>>> >
>>>> >
>>>> >>
>>>> >> Device client Server
>>>> >> ----> Get command
>>>> >> <-----<-----
>>>> >>
>>>> >> ----> ----> Response from device
>>>> >> <----- Response from server indicating
>>>> >> if it is ok or not the execution
>>>> >>
>>>> >> It would be like: client calls authenticate of device. then the server
>>>> >> sends the command to be sent to the device for authentication.
>>>> >
>>>> > HTTP authentication is orthogonal. Use one of the HTTP standard
>>>> authentication solutions.
>>>>
>>>> Authentication is done based on the crypto protocol that I explained above.
>>>>
>>>> >
>>>> >
>>>> >> The
>>>> >> client send this command to the device and the response is sent back
to
>>>> >> the server. The server then replies.
>>>> >>
>>>> >> I have thought on:
>>>> >> /device/{id} as resource
>>>> >> /device/{id}/authenticate
>>>> >> GET will retrieve the command and blank state
>>>> >> <command> value</command>
>>>> >> <state> not defined</command>
>>>> >> PUT will send the response and get the real state
>>>> >> ---> <response> value</response>
>>>> >> <---<state> not defined</command>
>>>> >>
>>>> >> I don't know if this is REST. Is it better to create another
>>>> resource as:
>>>> >> /device/{id}/authenticate/command (only GET available)
>>>> >> /device/{id}/authenticate/response (only PUT available)
>>>> >> /device/{id}/authenticate (only GET avaliable for status)
>>>> >>
>>>> >> Any help is welcome.
>>>> >
>>>> > Can you explain your requirements? I am having trouble understanding
>>>> what you are trying to do.
>>>>
>>>> The issue is that I need to get a command and then check the answer from
>>>> that command. This will be done in 2 steps, and I don't know how to map
>>>> that into resources.
>>>>
>>>> Thanks... hope now is clearer.
>>>>
>>>> CU
>>>> Jorge
>>>>
>>>> > Jan
>>>> >
>>>> >
>>>> >
>>>> >> TA
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> ------------------------------------
>>>> >>
>>>> >> Yahoo! Groups Links
>>>> >>
>>>> >>
>>>> >>
>>>> >
>>>> > -----------------------------------
>>>> > Jan Algermissen, Consultant
>>>> >
>>>> > Mail: algermissen@...<mailto:algermissen%40acm.org>
>>>> > Blog: http://www.nordsc.com/blog/<http://www.nordsc.com/blog/>
>>>> > Work: http://www.nordsc.com/<http://www.nordsc.com/>
>>>> > -----------------------------------
>>>> >
>>>> >
>>>> >
>>>>
>>>>
>>>
>>>
>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>
>
>
But SHOULD is not SHALL, is a recommendation not a imposition... So not having a body on a 201 could not be considered a violation of the spec... Wich indeed turns things more complicated in determining what a steady-state should be...
_________________________________________________
Melhores cumprimentos / Beir beannacht / Best regards
--- In rest-discuss@yahoogroups.com, Jan Algermissen <algermissen1971@...> wrote:
>
> When a client sends a POST request and receives a 201 Created...
>
> a) is the POST response body the steady state
>
> b) is it implied by HTTP spec that the client will do a GET on the Location and is that the steady state?
>
> c) is this up to the media type that contained the link to the POST-accepting resource?
>
>
>
> For other return codes I think this:
>
> 200 Ok - steady state is the POST response
> 202 Accepted - steady state is available at the link provided by the body of the 202 response
> 303 See Other - steady state is available ta resource that the Location points to
>
> Jan
>
I think the HTTP spec is pretty clear that 201 responses SHOULD have a body which constitutes your steady state.
Section 9.5:
If a resource has been created on the origin server, the response
SHOULD be 201 (Created) and contain an entity which describes the
status of the request and refers to the new resource, and a
Location header (see section 14.30)
Section 10.2.2:
The newly created resource can be referenced by the URI(s)
returned in the entity of the response, with the most specific URI
for the resource given by a Location header field. The response
SHOULD include an entity containing a list of resource
characteristics and location(s) from which the user or user agent
can choose the one most appropriate. The entity format is
specified by the media type given in the Content-Type header field.
I've always considered the Location header in 201 responses as information for intermediaries rather than the driver of application state. But I know I'm in the minority on that: a lot of people don't even have a body in their 201 responses (which to me is a violation of the spec).
Regards,
--- In rest-discuss@yahoogroups.com, Jan Algermissen <algermissen1971@...>
wrote:
>
>
> On Feb 2, 2010, at 4:16 AM, wahbedahbe wrote:
>
> >
> > --- In rest-discuss@yahoogroups.com, Jan Algermissen <algermissen1971@>
wrote:
> >> On Feb 1, 2010, at 2:54 PM, Mike Kelly wrote:
> >>> Jan Algermissen wrote:
> >>>> On Feb 1, 2010, at 1:38 PM, Mike Kelly wrote:
> >>>>> I think we need to agree on the definition of 'meaning' in this
> >>>>> context.. because, to me, it includes more than just the current set of
> >>>>> available link relations, and since we're not supposed to type resources
> >>>>> - the only approach I can see working is predefined application flows
> >>>>>
> >>>>
> >>>> Predefined application flows violate the hypermedia constraint and couple
the server in a way that REST deliberately aims to avoid.
> >>>>
> >>>
> >>> Predefined application flows like AtomPub violate the hypermedia
constraint?
> >>
> >> Yes. Roy confirmed that (recent post on atom-protocol list)
> >
> >
> > Really? Can you link to that? Was it the "MUST a collection be returned as
an Atom feed?" thread?
>
> Yep. http://www.imc.org/atom-protocol/mail-archive/msg11487.html
>
> >
> > I didn't read any of Roy's comments that way... or maybe I don't understand
what you mean by "AtomPub's predefined flow".
>
> The requirement that a GET on a collection returns an Atom feed. That is
unRESTful coupling because the client must not rely on such information but
react to whatever it gets at runtime.
>
> >
> > Do you mean the Service -> Feed -> Entry hierarchy?
>
> Yes, that's what it comes down to.
>
> >
> > You said yourself in that thread that <collection> and <image> played
conceptually similar roles. Isn't Page -> Image a similar two-level hierarchy?
What is wrong with that?
>
> <collection href=""> points to 'a collection', that is ok. But predefining the
media type that comes back from the collection is not. Might well be RSS or
text/uri-list
>
>
> >
> > I guess what I'm wondering is if AtomPub really defines an
> > "application flow" or do client writers mistake the hierarchy for one?
>
> A truly RESTful client would do a GET on the collection and treat any response
as 'correct' from a server POV (except for non-Collection representations, for
> example an audio file).
>
> Only if we do that the server's independent evolvability is preserved.
>
Ok... agree on the above, but how do you define 'collection'? To me it's
something that has a set of 'entries'. So you get the hierarchy don't you? A
'good' client can/should be flexible on the media types though (and the spec
shouldn't try to restrict them). Perhaps the variability in media type means
that the entries may be exclusively inline for some representations which just
means that the hierarchy might not map to your addressable resources, but it's
still there.
Andrew
--- In rest-discuss@yahoogroups.com, Jan Algermissen <algermissen1971@...>
wrote:
>
> When a client sends a POST request and receives a 201 Created...
>
> a) is the POST response body the steady state
>
> b) is it implied by HTTP spec that the client will do a GET on the Location
and is that the steady state?
>
> c) is this up to the media type that contained the link to the POST-accepting
resource?
>
>
>
> For other return codes I think this:
>
> 200 Ok - steady state is the POST response
> 202 Accepted - steady state is available at the link provided by the body of
the 202 response
> 303 See Other - steady state is available ta resource that the Location points
to
>
> Jan
>
I think the HTTP spec is pretty clear that 201 responses SHOULD have a body
which constitutes your steady state.
Section 9.5:
If a resource has been created on the origin server, the response
SHOULD be 201 (Created) and contain an entity which describes the
status of the request and refers to the new resource, and a
Location header (see section 14.30)
Section 10.2.2:
The newly created resource can be referenced by the URI(s)
returned in the entity of the response, with the most specific URI
for the resource given by a Location header field. The response
SHOULD include an entity containing a list of resource
characteristics and location(s) from which the user or user agent
can choose the one most appropriate. The entity format is
specified by the media type given in the Content-Type header field.
I've always considered the Location header in 201 responses as information for
intermediaries rather than the driver of application state. But I know I'm in
the minority on that: a lot of people don't even have a body in their 201
responses (which to me is a violation of the spec).
Regards,
Andrew
On 02/02/2010 14:31, António Mota wrote:
> I just read this on the diagonal, but it seems similar to what SyncML
> does, is that the case?
SyncML seems to be used to syncronized devices' (mobiles, handhelds,..)
information, such as contacts,... My case is not such a thing, as the
commands are for instance RS232 commands to be sent to a local device.
Thanks. Anyway I will read a little further SyncML (curiosity)
See you
>
> _________________________________________________
>
> Melhores cumprimentos / Beir beannacht / Best regards
>
> António Manuel dos Santos Mota
>
> http://card.ly/amsmota
> _________________________________________________
>
>
>
>
> 2010/2/2 George<george.news@...>:
>> Boing... any idea?
>>
>> On 01/02/2010 10:28, George wrote:
>>>
>>>
>>> Hi,
>>>
>>> Let's try to explain it a little further.
>>>
>>> On 01/02/2010 9:02, Jan Algermissen wrote:
>>> > George,
>>> >
>>> > On Jan 30, 2010, at 1:38 PM, George wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> I'm planning to develop a webservice, and I like to try the RESTful
>>> >> architecture.
>>> >>
>>> >> The service is about downloading some data from the server to a device
>>> >> attached on the local computer. The client need to retrieve the
command
>>> >> from the server and then send the response of the device to the server
>>> >> to check its validity. Then the server says if it is ok or not.
>>> >
>>> > I think I do not understand what you are up to. Why does the client
>>> fetch the command for the device from the server?
>>>
>>> The system is foreseen to control a hardware device. The issue is that
>>> the device only accepts a subset of commands based on some cryptographic
>>> features.
>>>
>>> I don't want the command set and the cryptographic keys to be on the
>>> client, as this way I have to replicate the keys on every client and the
>>> security can be comprised.
>>>
>>> Each command is encrypted with different keys depending on the device it
>>> is directed to. So the issue is first is that the server needs to know
>>> the device as to open the session with the correct set of keys. After
>>> that, the client get the command (encripted and maced with server keys),
>>> this command is sent to the device who will response. The response has
>>> some crypto stuff that need to be check on the server. Then the client
>>> get an ACK or NACK depending on the correct answer from the device
>>> (whether the command is well executed or not, or whether the device owns
>>> the correct set of keys and it not a fake device).
>>>
>>> >
>>> >
>>> >
>>> >>
>>> >> Device client Server
>>> >> ----> Get command
>>> >> <-----<-----
>>> >>
>>> >> ----> ----> Response from device
>>> >> <----- Response from server indicating
>>> >> if it is ok or not the execution
>>> >>
>>> >> It would be like: client calls authenticate of device. then the server
>>> >> sends the command to be sent to the device for authentication.
>>> >
>>> > HTTP authentication is orthogonal. Use one of the HTTP standard
>>> authentication solutions.
>>>
>>> Authentication is done based on the crypto protocol that I explained above.
>>>
>>> >
>>> >
>>> >> The
>>> >> client send this command to the device and the response is sent back
to
>>> >> the server. The server then replies.
>>> >>
>>> >> I have thought on:
>>> >> /device/{id} as resource
>>> >> /device/{id}/authenticate
>>> >> GET will retrieve the command and blank state
>>> >> <command> value</command>
>>> >> <state> not defined</command>
>>> >> PUT will send the response and get the real state
>>> >> ---> <response> value</response>
>>> >> <---<state> not defined</command>
>>> >>
>>> >> I don't know if this is REST. Is it better to create another
>>> resource as:
>>> >> /device/{id}/authenticate/command (only GET available)
>>> >> /device/{id}/authenticate/response (only PUT available)
>>> >> /device/{id}/authenticate (only GET avaliable for status)
>>> >>
>>> >> Any help is welcome.
>>> >
>>> > Can you explain your requirements? I am having trouble understanding
>>> what you are trying to do.
>>>
>>> The issue is that I need to get a command and then check the answer from
>>> that command. This will be done in 2 steps, and I don't know how to map
>>> that into resources.
>>>
>>> Thanks... hope now is clearer.
>>>
>>> CU
>>> Jorge
>>>
>>> > Jan
>>> >
>>> >
>>> >
>>> >> TA
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> ------------------------------------
>>> >>
>>> >> Yahoo! Groups Links
>>> >>
>>> >>
>>> >>
>>> >
>>> > -----------------------------------
>>> > Jan Algermissen, Consultant
>>> >
>>> > Mail: algermissen@...<mailto:algermissen%40acm.org>
>>> > Blog: http://www.nordsc.com/blog/<http://www.nordsc.com/blog/>
>>> > Work: http://www.nordsc.com/<http://www.nordsc.com/>
>>> > -----------------------------------
>>> >
>>> >
>>> >
>>>
>>>
>>
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>
I just read this on the diagonal, but it seems similar to what SyncML
does, is that the case?
_________________________________________________
Melhores cumprimentos / Beir beannacht / Best regards
António Manuel dos Santos Mota
http://card.ly/amsmota
_________________________________________________
2010/2/2 George <george.news@...>:
> Boing... any idea?
>
> On 01/02/2010 10:28, George wrote:
>>
>>
>> Hi,
>>
>> Let's try to explain it a little further.
>>
>> On 01/02/2010 9:02, Jan Algermissen wrote:
>> > George,
>> >
>> > On Jan 30, 2010, at 1:38 PM, George wrote:
>> >
>> >> Hi,
>> >>
>> >> I'm planning to develop a webservice, and I like to try the RESTful
>> >> architecture.
>> >>
>> >> The service is about downloading some data from the server to a device
>> >> attached on the local computer. The client need to retrieve the command
>> >> from the server and then send the response of the device to the server
>> >> to check its validity. Then the server says if it is ok or not.
>> >
>> > I think I do not understand what you are up to. Why does the client
>> fetch the command for the device from the server?
>>
>> The system is foreseen to control a hardware device. The issue is that
>> the device only accepts a subset of commands based on some cryptographic
>> features.
>>
>> I don't want the command set and the cryptographic keys to be on the
>> client, as this way I have to replicate the keys on every client and the
>> security can be comprised.
>>
>> Each command is encrypted with different keys depending on the device it
>> is directed to. So the issue is first is that the server needs to know
>> the device as to open the session with the correct set of keys. After
>> that, the client get the command (encripted and maced with server keys),
>> this command is sent to the device who will response. The response has
>> some crypto stuff that need to be check on the server. Then the client
>> get an ACK or NACK depending on the correct answer from the device
>> (whether the command is well executed or not, or whether the device owns
>> the correct set of keys and it not a fake device).
>>
>> >
>> >
>> >
>> >>
>> >> Device client Server
>> >> ----> Get command
>> >> <-----<-----
>> >>
>> >> ----> ----> Response from device
>> >> <----- Response from server indicating
>> >> if it is ok or not the execution
>> >>
>> >> It would be like: client calls authenticate of device. then the server
>> >> sends the command to be sent to the device for authentication.
>> >
>> > HTTP authentication is orthogonal. Use one of the HTTP standard
>> authentication solutions.
>>
>> Authentication is done based on the crypto protocol that I explained above.
>>
>> >
>> >
>> >> The
>> >> client send this command to the device and the response is sent back to
>> >> the server. The server then replies.
>> >>
>> >> I have thought on:
>> >> /device/{id} as resource
>> >> /device/{id}/authenticate
>> >> GET will retrieve the command and blank state
>> >> <command> value</command>
>> >> <state> not defined</command>
>> >> PUT will send the response and get the real state
>> >> ---> <response> value</response>
>> >> <---<state> not defined</command>
>> >>
>> >> I don't know if this is REST. Is it better to create another
>> resource as:
>> >> /device/{id}/authenticate/command (only GET available)
>> >> /device/{id}/authenticate/response (only PUT available)
>> >> /device/{id}/authenticate (only GET avaliable for status)
>> >>
>> >> Any help is welcome.
>> >
>> > Can you explain your requirements? I am having trouble understanding
>> what you are trying to do.
>>
>> The issue is that I need to get a command and then check the answer from
>> that command. This will be done in 2 steps, and I don't know how to map
>> that into resources.
>>
>> Thanks... hope now is clearer.
>>
>> CU
>> Jorge
>>
>> > Jan
>> >
>> >
>> >
>> >> TA
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> ------------------------------------
>> >>
>> >> Yahoo! Groups Links
>> >>
>> >>
>> >>
>> >
>> > -----------------------------------
>> > Jan Algermissen, Consultant
>> >
>> > Mail: algermissen@... <mailto:algermissen%40acm.org>
>> > Blog: http://www.nordsc.com/blog/ <http://www.nordsc.com/blog/>
>> > Work: http://www.nordsc.com/ <http://www.nordsc.com/>
>> > -----------------------------------
>> >
>> >
>> >
>>
>>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
Boing... any idea?
On 01/02/2010 10:28, George wrote:
>
>
> Hi,
>
> Let's try to explain it a little further.
>
> On 01/02/2010 9:02, Jan Algermissen wrote:
> > George,
> >
> > On Jan 30, 2010, at 1:38 PM, George wrote:
> >
> >> Hi,
> >>
> >> I'm planning to develop a webservice, and I like to try the RESTful
> >> architecture.
> >>
> >> The service is about downloading some data from the server to a device
> >> attached on the local computer. The client need to retrieve the command
> >> from the server and then send the response of the device to the server
> >> to check its validity. Then the server says if it is ok or not.
> >
> > I think I do not understand what you are up to. Why does the client
> fetch the command for the device from the server?
>
> The system is foreseen to control a hardware device. The issue is that
> the device only accepts a subset of commands based on some cryptographic
> features.
>
> I don't want the command set and the cryptographic keys to be on the
> client, as this way I have to replicate the keys on every client and the
> security can be comprised.
>
> Each command is encrypted with different keys depending on the device it
> is directed to. So the issue is first is that the server needs to know
> the device as to open the session with the correct set of keys. After
> that, the client get the command (encripted and maced with server keys),
> this command is sent to the device who will response. The response has
> some crypto stuff that need to be check on the server. Then the client
> get an ACK or NACK depending on the correct answer from the device
> (whether the command is well executed or not, or whether the device owns
> the correct set of keys and it not a fake device).
>
> >
> >
> >
> >>
> >> Device client Server
> >> ----> Get command
> >> <-----<-----
> >>
> >> ----> ----> Response from device
> >> <----- Response from server indicating
> >> if it is ok or not the execution
> >>
> >> It would be like: client calls authenticate of device. then the server
> >> sends the command to be sent to the device for authentication.
> >
> > HTTP authentication is orthogonal. Use one of the HTTP standard
> authentication solutions.
>
> Authentication is done based on the crypto protocol that I explained above.
>
> >
> >
> >> The
> >> client send this command to the device and the response is sent back to
> >> the server. The server then replies.
> >>
> >> I have thought on:
> >> /device/{id} as resource
> >> /device/{id}/authenticate
> >> GET will retrieve the command and blank state
> >> <command> value</command>
> >> <state> not defined</command>
> >> PUT will send the response and get the real state
> >> ---> <response> value</response>
> >> <---<state> not defined</command>
> >>
> >> I don't know if this is REST. Is it better to create another
> resource as:
> >> /device/{id}/authenticate/command (only GET available)
> >> /device/{id}/authenticate/response (only PUT available)
> >> /device/{id}/authenticate (only GET avaliable for status)
> >>
> >> Any help is welcome.
> >
> > Can you explain your requirements? I am having trouble understanding
> what you are trying to do.
>
> The issue is that I need to get a command and then check the answer from
> that command. This will be done in 2 steps, and I don't know how to map
> that into resources.
>
> Thanks... hope now is clearer.
>
> CU
> Jorge
>
> > Jan
> >
> >
> >
> >> TA
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> ------------------------------------
> >>
> >> Yahoo! Groups Links
> >>
> >>
> >>
> >
> > -----------------------------------
> > Jan Algermissen, Consultant
> >
> > Mail: algermissen@... <mailto:algermissen%40acm.org>
> > Blog: http://www.nordsc.com/blog/ <http://www.nordsc.com/blog/>
> > Work: http://www.nordsc.com/ <http://www.nordsc.com/>
> > -----------------------------------
> >
> >
> >
>
>
When a client sends a POST request and receives a 201 Created...
a) is the POST response body the steady state
b) is it implied by HTTP spec that the client will do a GET on the Location and
is that the steady state?
c) is this up to the media type that contained the link to the POST-accepting
resource?
For other return codes I think this:
200 Ok - steady state is the POST response
202 Accepted - steady state is available at the link provided by the body of
the 202 response
303 See Other - steady state is available ta resource that the Location points
to
Jan
Jan Algermissen wrote:
> On Feb 2, 2010, at 11:25 AM, Mike Kelly wrote:
>
>
>> Jan Algermissen wrote:
>>
>>> On Feb 2, 2010, at 4:16 AM, wahbedahbe wrote:
>>>
>>>
>>>
>>>> --- In rest-discuss@yahoogroups.com, Jan Algermissen <algermissen1971@...>
wrote:
>>>>
>>>>
>>>>> On Feb 1, 2010, at 2:54 PM, Mike Kelly wrote:
>>>>>
>>>>>
>>>>>> Jan Algermissen wrote:
>>>>>>
>>>>>>
>>>>>>> On Feb 1, 2010, at 1:38 PM, Mike Kelly wrote:
>>>>>>>
>>>>>>>
>>>>>>>> I think we need to agree on the definition of 'meaning' in this
>>>>>>>> context.. because, to me, it includes more than just the current set of
>>>>>>>> available link relations, and since we're not supposed to type
resources
>>>>>>>> - the only approach I can see working is predefined application flows
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Predefined application flows violate the hypermedia constraint and
couple the server in a way that REST deliberately aims to avoid.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Predefined application flows like AtomPub violate the hypermedia
constraint?
>>>>>>
>>>>>>
>>>>> Yes. Roy confirmed that (recent post on atom-protocol list)
>>>>>
>>>>>
>>>> Really? Can you link to that? Was it the "MUST a collection be returned as
an Atom feed?" thread?
>>>>
>>>>
>>> Yep. http://www.imc.org/atom-protocol/mail-archive/msg11487.html
>>>
>>>
>> That post is about over-specification, not predefinition. And leads me
>> to ask - What is an 'adequate specification', if not predefinition?
>>
>
> I understood Roy to be saying that it is an over-specifiction that AtomPub
requires GETs on collections to return an Atom feed.
>
> Such a predefinition is an over-specification in RESTland.
>
> Jan
>
Maybe so, but the use of term "over" specification implies that there is
infact an appropriate degree of specification i.e. a predefined flow
with a more suitable level of liberalism.
- Mike
On Feb 2, 2010, at 11:25 AM, Mike Kelly wrote:
> Jan Algermissen wrote:
>> On Feb 2, 2010, at 4:16 AM, wahbedahbe wrote:
>>
>>
>>> --- In rest-discuss@yahoogroups.com, Jan Algermissen <algermissen1971@...>
wrote:
>>>
>>>> On Feb 1, 2010, at 2:54 PM, Mike Kelly wrote:
>>>>
>>>>> Jan Algermissen wrote:
>>>>>
>>>>>> On Feb 1, 2010, at 1:38 PM, Mike Kelly wrote:
>>>>>>
>>>>>>> I think we need to agree on the definition of 'meaning' in this
>>>>>>> context.. because, to me, it includes more than just the current set of
>>>>>>> available link relations, and since we're not supposed to type resources
>>>>>>> - the only approach I can see working is predefined application flows
>>>>>>>
>>>>>>>
>>>>>> Predefined application flows violate the hypermedia constraint and couple
the server in a way that REST deliberately aims to avoid.
>>>>>>
>>>>>>
>>>>> Predefined application flows like AtomPub violate the hypermedia
constraint?
>>>>>
>>>> Yes. Roy confirmed that (recent post on atom-protocol list)
>>>>
>>> Really? Can you link to that? Was it the "MUST a collection be returned as
an Atom feed?" thread?
>>>
>>
>> Yep. http://www.imc.org/atom-protocol/mail-archive/msg11487.html
>>
>
> That post is about over-specification, not predefinition. And leads me
> to ask - What is an 'adequate specification', if not predefinition?
I understood Roy to be saying that it is an over-specifiction that AtomPub
requires GETs on collections to return an Atom feed.
Such a predefinition is an over-specification in RESTland.
Jan
>
> - Mike
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
-----------------------------------
Jan Algermissen, Consultant
NORD Software Consulting
Mail: algermissen@...
Blog: http://www.nordsc.com/blog/
Work: http://www.nordsc.com/
-----------------------------------
Jan Algermissen wrote:
> On Feb 2, 2010, at 4:16 AM, wahbedahbe wrote:
>
>
>> --- In rest-discuss@yahoogroups.com, Jan Algermissen <algermissen1971@...>
wrote:
>>
>>> On Feb 1, 2010, at 2:54 PM, Mike Kelly wrote:
>>>
>>>> Jan Algermissen wrote:
>>>>
>>>>> On Feb 1, 2010, at 1:38 PM, Mike Kelly wrote:
>>>>>
>>>>>> I think we need to agree on the definition of 'meaning' in this
>>>>>> context.. because, to me, it includes more than just the current set of
>>>>>> available link relations, and since we're not supposed to type resources
>>>>>> - the only approach I can see working is predefined application flows
>>>>>>
>>>>>>
>>>>> Predefined application flows violate the hypermedia constraint and couple
the server in a way that REST deliberately aims to avoid.
>>>>>
>>>>>
>>>> Predefined application flows like AtomPub violate the hypermedia
constraint?
>>>>
>>> Yes. Roy confirmed that (recent post on atom-protocol list)
>>>
>> Really? Can you link to that? Was it the "MUST a collection be returned as an
Atom feed?" thread?
>>
>
> Yep. http://www.imc.org/atom-protocol/mail-archive/msg11487.html
>
That post is about over-specification, not predefinition. And leads me
to ask - What is an 'adequate specification', if not predefinition?
- Mike
On Feb 2, 2010, at 12:48 AM, piers_lawson wrote:
>
>
> Thank you for your replies.
>
> I think both Craig and Eric agree that a collection of "links" to resources
should be returned to the client in a form that is not simply a cut-down version
of the actual resource, but is clearly a link. Eric then goes further to
suggest that by re-using a well known specification, anybody writing a client
gets the benefit of reusing knowledge (and possibly tools) they already have.
>
> I will look more closely at the Atom specification to see how well it fits my
situation... though I have one immediate question:
>
> As stated originally, I wanted my representation of the Seller resource to
contain both the Seller information and the collection of links to Accounts. I
don't want the Seller representation to be a Service Document that contains
pointers to the feeds, which the client would then have to GET separately. How
would you mix one or more feeds into the representation of a resource? Would you
have something along the lines of:
>
> <seller .....>
>
> <otherInfo1 />
>
> <otherInfo2 />
>
> <feed xmlns="http://www.w3.org/2005/Atom">
> <title>Accounts</title>
>
> ...
>
> <entry>...</entry>
>
> <entry>...</entry>
>
> </feed>
>
> </seller>
>
> If so, what media type should be used? Neither "application/atomserv+xml" or
"application/atom+xml" seem appropriate.
>
> I understand the benefits of re-using a standard but worry about the verbosity
compared to a custom representation.
Since you have a custom <seller> anyhow, I'd - for the sake of clarity - just
use custom markup for the account links, too. You might still provide an extra
resource that is the collection of accounts and provide a feed for that.
e.g.
<seller>
...
<accounts href="">
<account .....>
<account ....>
</accouts>
</seller>
Jan
> I also wonder about the real benefits when the client will have to be built to
understand the "foreign markup" anyway if it is to be of any use to an end user.
>
> I think I might be sold more on the idea if I could see an example of this
embedding of feeds into a representation or a resource.
>
> Thank you for your time
>
> Piers
>
>
>
>
-----------------------------------
Jan Algermissen, Consultant
Mail: algermissen@...
Blog: http://www.nordsc.com/blog/
Work: http://www.nordsc.com/
-----------------------------------
Send Email
Offline 
