> So yes, a REST API must rely on media types to determine the semantics
> of protocol methods.  Using HTTP DELETE on a resource represented only
> as text/html isn't RESTful now, but it may become so once HTML 5 has
> added (hopefully at least) PUT and DELETE into the text/html realm, at
> which point they can be hypertext-driven.

I ended up taking time to read your entire message and I think the
above paragraph represents our differences.  I *think* this is wrong.
That 'text/html' doesn't support DELETE is a flaw in a single
representation - the "resource" is still DELETEable as I have a *link*
and a DELETE method that's a part of the interface.  If I have a URI
to a resource, the HTTP interface allows me to DELETE it.  I'll say
again, I think the intent is that the methods of the uniform interface
are the interface between *system components* and to be applied to
resources independent of a representation.  One way to effect behavior
changes would be to change the granularity of resources being exposed
- as opposed to specifying semantics for a specific representation or
resource.

I *think* this is what Roy was addressing when he wrote this:

"Identifiers, methods, and media types are orthogonal concerns —
methods are not given meaning by the media type. Instead, the media
type tells the client either what method to use (e.g., anchor implies
GET) or how to determine the method to use (e.g., form element says to
look in method attribute). The client should already know what the
methods mean (they are universal) and how to dereference a URI."

--tim

[1] -
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-73\
0

On Mon, Dec 21, 2009 at 7:07 PM, Eric J. Bowman <eric@...> wrote:
> "Eric J. Bowman" wrote:
>>
>> So my client extends Atom Protocol by self-describing the unspecified
>> behavior of DELETE on a collection, in two different user-selectable
>> ways, using hypertext to drive application state and avoiding Atom
>> Protocol's REST mismatch on DELETE for both collections and member
>> resources.  Client and server are now decoupled, and may evolve
>> independently.
>>
>
> My system also extends Atom Protocol through the use of PATCH.  The
> system is a basic weblog, with multiple authors, plus registered and
> unregistered users.  Role-based security is implemented (using HTTP-
> Digest) per HTTP method:  Authors may POST new articles and PUT
> edits to their own articles.  Registered users may POST new comments
> and, for a limited time, PUT edits to their own comments.  Unregistered
> users may POST comments.  Only Administrator-authors may DELETE
> anything.
>
> What I want, is for authors and registered users to be able to change
> the tags associated with an article.  If I follow Atom Protocol and do
> this with PUT, then I'm breaking my security model by allowing any
> author or registered user to potentially edit the article

As I said in the other mail, it seems that your problem is created by
following APP even when it doesn't give you the desired level of
resource granularity.  You *could* leave it the way it is and let only
authors modify that resource, then expose a completely new resource
[tags] which you allow more liberal access to.

--tim

On Mon, Dec 21, 2009 at 2:36 AM, Eric J. Bowman <eric@...> wrote:
> "Eric J. Bowman" wrote:
>>
>> Sorry, not PUT, I was thinking about something else.  But there is a
>> minor REST mismatch in AtomPub regarding DELETE not being hypertext-
>> driven, an obvious coupling of client to server.  But, as a small
>> portion of an overall REST system, not enough to claim failure to
>> apply the hypertext constraint -- just a nitpick.  While Atom Protocol
>> doesn't specify the behavior of DELETE on a collection, this
>> disclaimer still scopes DELETE to any resource with an Atom
>> representation.
>>
>
> Going a bit OT:
>
> I keep forgetting that I wrote a minimally-featured Atom Protocol
> client using Xforms, to address this REST mismatch.  An Xforms REST
> application follows the MVC architectural style on the client.  An
> XHTML interface is provided, which takes an Atom collection feed and
> displays it as one big Xform allowing individual entries to be added,
> edited or removed by directly manipulating the Atom resources,
> depending on user role as provided by HTTP-Digest.  A form button may
> be added to any individual entry, which will call its DELETE method,
> meeting the hypertext constraint that eludes other Atom Protocol
> implementations.
>
> Part of the Xform allows the collection to be deleted in one of three
> ways:  DELETE all members, DELETE the collection but not its members, or
> DELETE all members and then DELETE the collection.  While having a
> collection-targeted DELETE silently remove all member resources of the
> collection, then remove the collection resource, has the "Roy stamp of
> approval" I do not wish to go that route here. My way is visible,
> because batch deletion occurs as separate DELETE requests to each
> member resource.

It seems to me this isn't a "REST mismatch" so much as a mismatch
between your desires and what APP gives you.  I don't know APP well,
but it seems that the real problem is that APP doesn't expose the
collection at the level of granularity that you desire.  When I read
your paragraph above, I see three "resources" (collection, contents,
and collection+contents).  If you want them to be able to be DELETEd
independently, you'll need to craft their exposure individually.  I
don't know, other than the fact that you're fighting with a protocol
on top of HTTP, it doesn't seem a lot different than any other
REST-resource problem that might be fixed by changing the resources
exposed, even if that means moving away from APP.

--tim

Eric,
First, a disclaimer... I didn't read your entire message.  As with
your other threads, your verbosity has overwhelmed the little time I
have to participate in this discussion...  I apologize, it's
interesting stuff otherwise...

On Mon, Dec 21, 2009 at 9:36 PM, Eric J. Bowman <eric@...> wrote:
> On Mon, 21 Dec 2009 11:53:59 -0500
> Tim Williams wrote:
>>
>> My original contention was that 'calling DELETE' on some resource
>> (URI) provided by the server, isn't 'going rogue' or violating the
>> uniform interface even if it's not in the representation.  It may be
>> met with a 405, but since "DELETE" is a part of the uniform interface
>> between components in the system, I don't see how using it might be
>> considered a violation of it.
>>
>
> Careful -- DELETE is a protocol-independent generic-interface method,
> the HTTP implementation of which doesn't automatically result in a
> uniform REST interface.  As with most methods.  My Xforms Atom Protocol
> client, discussed here:

This is strange, I'm personally not after a holy grail of
cross-communications protocol interface uniformity.  I'm specifically
talking about an "HTTP-based implementation of the REST style."  In
this case, the HTTP spec gets to define the methods and their
semantics.  Any protocol riding on top of HTTP should only be
"filling-out or fixing the details of underspecified bits of standard
protocols"[1].  My point was that this interface is defined as the
interface between system components - independent of a representation
(e.g. that HTML leaves off DELETE doesn't mean it's not a part of the
interface).  Your problem(s) that I've seen seem to be related to the
fact that you've constrained yourself to a protocol that doesn't give
you your desired level of resource granularity, such that it results
in undefined behavior.

--tim

On 21 Dec 2009, at 04:26, Eric J. Bowman wrote:

> My suggestion is to dredge up and dust off ye olde shopping-cart
> example.

OK.

> In brief:  Define resources in terms of standard media types and link
> relations, saving URI allocation and method selection for the
> implementation phase.

Nearly right, but I would de-emphasise media types, until the last moment.

Here is how to go about it.

1. Take a problem the is not client server specific. Ie: try something that
spans domains, that requires distributed cooperation among agents. eg: Social
Networks. Think big, and built simple.

2. define your models using RDF. Take an example on foaf:

    http://xmlns.com/foaf/0.1/

    (and publish those models as linked data, so we have recursion)

3. Create Linked Data using those models.
    Build linked data examples that span across domains. Ie. one resource is
defined on my site, the other on yours and link between them. FOAF is a good
example of this.

   see for example how the data in this file points to data others have on their
web site

   curl  http://bblfish.net/people/henry/card

    You can choose one or more media types to do this, with content negotiation.
Ie: the same URL can return any number of representations: html, rdf/xml, n3,
...

4. Create browsers of linked data

   eg, the foaf address book
   https://sommer.dev.java.net/AddressBook.html
   or web versions of the same
   http://foaf-visualizer.org/

5. Add security restfully

   eg, foaf+ssl
   http://esw.w3.org/topic/foaf+ssl

6. Now you can do shopping, in a RESTful manner using the GoodRelations ontology
for example
    http://purl.org/goodrelations/
    You probably just need to define certain types of resources, as being
ShoppingCarts, and actions that one needs to do on those to make it possible for
people to create buying agents.

On Dec 22, 2009, at 8:22 AM, Stefan Tilkov wrote:

> On Dec 22, 2009, at 1:38 AM, Subbu Allamaraju wrote:
>
>>
>> On Dec 21, 2009, at 4:07 PM, Eric J. Bowman wrote:
>>
>>> Sure, this implementation is architecturally sound, but I have to
>>> put
>>> up my asterisk stating that this portion of my API is not
>>> standardized,
>>> and is therefore not REST. Currently, by virtue of Xforms 1.1
>>> allowing
>>
>> I must say that this is an extreme interpretation. You are implying
>> that any hint of non-standardness makes an app unRESTful. Not even
>> the underlying standards of the web require such strict adherence.
>
> I second that.

+1

Besides - what is a standard anyway? IETF? OASIS? W3C? Google? What
matters is that the hypermedia semantics used are properly specified
and made available on the Web so clients can "follow their nose".

Jan


> Quoting from one of Roy's posts [1]:
>
> "I should also note that the above is not yet fully RESTful, at
> least how I use the term. All I have done is described the service
> interfaces, which is no more than any RPC. In order to make it
> RESTful, I would need to add hypertext to introduce and define the
> service, describe how to perform the mapping using forms and/or link
> templates, and provide code to combine the visualizations in useful
> ways. I could even go further and define these relationships as a
> standard, much like Atom has standardized a normal set of HTTP
> relationships with expected semantics, but I have bigger fish to fry
> right now."
>
> Seems to me that even Roy believes standardization is a desired, but
> not mandatory, property of RESTful systems.
>
> Stefan
>
>
> [1] http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-dragons
>
>>
>> Besides being questionable, such an interpretation is not very
>> useful. What is the end goal here? Striving to ensure that an app
>> meet this interpretation, or is it to deliver something of value to
>> the stakeholders? If providing value to the stakeholders requires
>> use of *everything* standard, then that is what should guide an
>> implementation.
>>
>> Subbu
>>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

--------------------------------------
Jan Algermissen

Mail: algermissen@...
Blog: http://algermissen.blogspot.com/
Home: http://www.jalgermissen.com
--------------------------------------

On Dec 22, 2009, at 3:15 AM, Noah Campbell wrote:

> See below...
>
> On Mon, Dec 21, 2009 at 3:16 PM, Jan Algermissen <algermissen1971@...
> > wrote:
>
> On Dec 21, 2009, at 11:47 PM, Noah Campbell wrote:
>
>
>
> "This would lead to "If you are going to adopt REST with all the
> benefits do it all the way through and believe that the business
> level harm occasionally done by evolution costs far less than
> running a SOAP architecture in the long run."
>
> Basically, no.  If your notion that SOAP somehow solved the problems
> that you've identified being an issue in REST then I'm curious how
> you over came SOAP's shortcoming's.  If anything, SOAP is more rigid
> and this leads to increase cost in the face of change.  This has
> nothing to do with SOAP the architecture, but more SOAP the
> implementation.  WSDL has done more harm than good, IMO.  I've seen
> POX work really well, but again it's a different architecture than
> REST.
>
> I'm curious how SLA enforcement is achieved with a SOAP architecture?
>
>
> That is simple with SOAP because the artifact to enforce is the API.
>
> WSDL being the API artifact here?

Yes, (at least that is what I think).
>
> The SLA would be around the API lifecycle (e.g. once an API is out,
> it has to persist for three years). Not saying that the API is a
> sufficient means to guarantee stability but it expresses a fixed
> contract. WS-* simply excludes evolution without explicit versioning
> (doo, hope that is really correct; not an expert there). The SLA
> would only be violated if an existing API would go away. The
> evolution issue is done away with by tightly coupling the components.
>
> The evolution is done away with to the point that it's very
> difficult to change anything in practice.  It's my opinion that
> tight coupling is actually a risk/liability,

Yes, of course.

> but I digress.
>
> Versioning is one means of controlling evolution and RESTful
> architecture supports it.  There are numerous ways to achieve a
> transition from one version to the next.  SOAP has options as well,
> but it can't take advantage of intermediaries to aide in the
> transition.
>
> For example, a RESTful architecture based on HTTP can use an HTTP
> load balancer to direct traffic to another version (via 301/307 or
> through pass through proxy) because it can take advantage of the
> URLs for uniquely identifying a resource.  SOAP isn't so lucky since
> it tunnels through one URL, i.e. /context/service, and the proxy
> would have to inspect the payload to know where to route it (que the
> ESB vendor sales pitch here).  SOAP may present the appearance of an
> artifact to establish a SLA, but it may be a false sense of stability.

Yes.

>
>
>
> I've also seen RESTful system that include configuration as the
> first transition in the client state.  The first response to a url
> is a document (xhtml, atom, xml) that has relationships a client
> becomes tightly coupled to.  A rel tag with "apiv2" and a link to
> the v2 version of the service.  The server cannot retire until all
> clients evolve to a new version.  The client can start to evolve
> when a new version is made available (they can be done in parallel,
> but this is an optimization) and the client code is rolled out.  v2
> and v3 of the site can be running side by side if necessary.

Yes.


Jan

>
>
> (AFAIK anyway)
>
> Jan
>
>
>
> -Noah
>
> On Mon, Dec 21, 2009 at 1:18 PM, Jan Algermissen <algermissen1971@...
> > wrote:
> Noah,
>
> (see below),
>
>
> On Dec 21, 2009, at 8:19 PM, Noah Campbell wrote:
>
> "AtomPub for example enables the client *implementor* to assume that
> a GET on a collection will return an Atom feed document."
>
> To your prior point, something is broken, but what?  Is it the
> architectural style (by asking it on this mailing list it may be
> that you think it is)?  Is it the transport HTTP?  Is it the
> specification?  Is it the implementor of the server or the client?
> Is it something else?
>
> You focus on the assumption being negative and rightly so, but lets
> be formal about what an assumption is.  You've alluded to an
> assumption not met as negative.
>
> I is usually not that negative on the open Web because the overall
> expectations are not that strict; people allways plan for any kinds
> of changes to happen and REST advantage here is that the uniform
> interface enables the communication (the talking to each other) to
> succeed even if there is an error. Instead of everything falling
> apart the client user or developer can pick up the clue (e.g. the
> 406 body) and follow her nose to fix things.
>
> But this is a model that is very hard to sell inside the enterprise
> because the business level contracts require a certain degree of
> certainty (e.g. SLAs). Saying "hey, if business transactions
> suddenly stop working, look at the lock file and see what the
> service owner suggested as a fix. Nah, this will not happen evry
> often, just be prepared for it in any case".
>
> OTH, it might be the price to pay for the evolvability extreme of
> not needing any kind of out of band communication between client and
> server developer at all. Possibly, if you compare investment in time
> and travel resources etc. involved in discussing interfaces of the
> SOAP style with the cost of some missing transactions it might even
> make a compelling case. (Like airline rather pay customers some
> money for overbooked flights than to make sure that every passenger
> definitely gets a seat. The latter just costs less).
>
> This would lead to "If you are going to adopt REST with all the
> benefits do it all the way through and believe that the business
> level harm occasionally done by evolution costs far less than
> running a SOAP architecture in the long run.
>
>
> If I had to translate this into code it would look like this:
>
> fread (buffer, 1, lSize, pFile)
>
> There is an assumption here given all the variables are initialized
> correctly.  Do you see it?
>
> The return value is not checked.  The read may not have read all the
> data in the file in this particular call.  Who is the guilty party?
> Is it the architecture, POSIX?  Is it the
specification,http://www.cplusplus.com/reference/clibrary/cstdio/fread/?
>  Is it the implementation, GNU? Is it the implementor?  I'd argue
> it's the implementor.  C has a long established history of using
> return values to indicate success (as well as return values...but
> errno provides a (kludgy?) workaround).
>
> I would urge an implementer to understand the architecture style,
> the specification, the implementation and focus very hard on making
> sure assumptions like the above are not scattered through out the
> code.  Since REST is about two remote systems communicating, I'd
> argue that any client must validate any assumption before
> proceeding, including checking the error code.  If not, the client
> will be be brittle, prone to error, and cost more in ongoing
> maintenance.  Good, robust applications assume nothing.
>
> Let's assume for a moment the AtomPub spec represents the typical
> spec for a service.  It assumes RESTful architectural style using
> the HTTP transport.  To your point, the service must behave has
> specified for any goal to be obtained.   Aspects of the http
> transport "leak" into the interaction even those it has not been
> specified.  The spec doesn't call out all the different response
> codes and how to handle them, it relies on those familiar with the
> HTTP transport to deal with those gracefully.  Case in point, if you
> do:
>
> GET /
> Accept: application/atomsvc+xml
>
> and get a
>
> 307: Moved Temporarily
> Location: /svc.atom
>
> or
>
> 305: Use Proxy
> Location: /proxy/svc.atom
>
> or
>
> 401: Unauthorized
> www-authenticate: basic
>
> Is this an error?
>
> Roy thesis doesn't explicitly say yes or no.  However, the argument
> for a uniform interface is that the intermediary can participate
> without affecting the remote call.  I'll extrapolate a little in
> that a uniform interface provides a common behavior that permeates
> all levels of an architecture, including the implementation.  The
> testers should be not be surprised to see the 3 response outline
> above and should be able to accommodate appropriately.
>
>
> Agreed and I see your point. But (sorry :-) I'd expect an HTTP
> client connector to be able to follow these redirects or
> authenticate on its own without even propagating it to the next
> level. Most client connectors do so (depending on config of course).
> So, I'd limit what we are talking about to steady states and leave
> out the transient ones.
>
> However, I understand you to say that an AtomPub client
> implementation that uses an HTTP client connector must of course
> implement all of HTTP. And yes, I agree that the 406 must be handled
> correctly. But then? there is no possible recovery from the broken
> expectation to receive an Atom feed.
>
>
>
> Hopefully this response helps move the discussion forward :)
>
> Thanks for keeping up with this. I am just sorry that I seem to be
> so unable to get this accross.
>
> Jan
>
>
>
>
> -Noah
>
> On Mon, Dec 21, 2009 at 4:35 AM, Jan Algermissen <algermissen1971@...
> > wrote:
>
> On Dec 21, 2009, at 1:25 PM, Jorn Wildt wrote:
>
> > Oh, lets backtrack a bit. You said earlier on:
> >
> >> In the enterprise people want to develop clients and services in
> >> parallel, shich rules out client design by inspecting the runtime
> >> behavior of a service.
> >
> > Then I said: you need not expect at runtime, you can have a mock. To
> > this you answered: no, you build clients on specs.
> >
> > What I was trying to say was: if you build clients on specs and RFC
> > 5023 (application/atomsrv+xml) is a spec, then what is keeping you
> > from building any kind of REST client on similar specs for other
> > media types? If both server and client agrees on the media type spec
> > then both can be built individually and simultaneously.
>
>
> No, that is all fine and I agree. I am questioning the RESTfulness of
> specs that allow the clients to make assumptions about the hypermedia
> it will receive at some point in the interaction. AtomPub for example
> enables the client *implementor* to assume that a GET on a collection
> will return an Atom feed document. This is equivalent to making an
> assumption about the application state to be in after the GET to the
> collection.
>
> And I am trying to say that M2M clients (besides passibe, server
> driven crawlers) can only be built when such contracts are in place.
>
> Jan
>
>
> >
> > /Jørn
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>
> --------------------------------------
> Jan Algermissen
>
> Mail: algermissen@...
> Blog: http://algermissen.blogspot.com/
> Home: http://www.jalgermissen.com
> --------------------------------------
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>
> --------------------------------------
> Jan Algermissen
>
> Mail: algermissen@...
> Blog: http://algermissen.blogspot.com/
> Home: http://www.jalgermissen.com
> --------------------------------------
>
>
>
>
>
>
>
>
> --------------------------------------
> Jan Algermissen
>
> Mail: algermissen@...
> Blog: http://algermissen.blogspot.com/
> Home: http://www.jalgermissen.com
> --------------------------------------
>
>
>
>

--------------------------------------
Jan Algermissen

Mail: algermissen@...
Blog: http://algermissen.blogspot.com/
Home: http://www.jalgermissen.com
--------------------------------------

On Dec 22, 2009, at 1:38 AM, Subbu Allamaraju wrote:

>
> On Dec 21, 2009, at 4:07 PM, Eric J. Bowman wrote:
>
> > Sure, this implementation is architecturally sound, but I have to put
> > up my asterisk stating that this portion of my API is not standardized,
> > and is therefore not REST. Currently, by virtue of Xforms 1.1 allowing
>
> I must say that this is an extreme interpretation. You are implying that any
hint of non-standardness makes an app unRESTful. Not even the underlying
standards of the web require such strict adherence.

I second that. Quoting from one of Roy's posts [1]:

"I should also note that the above is not yet fully RESTful, at least how I use
the term. All I have done is described the service interfaces, which is no more
than any RPC. In order to make it RESTful, I would need to add hypertext to
introduce and define the service, describe how to perform the mapping using
forms and/or link templates, and provide code to combine the visualizations in
useful ways. I could even go further and define these relationships as a
standard, much like Atom has standardized a normal set of HTTP relationships
with expected semantics, but I have bigger fish to fry right now."

Seems to me that even Roy believes standardization is a desired, but not
mandatory, property of RESTful systems.

Stefan


[1] http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-dragons

>
> Besides being questionable, such an interpretation is not very useful. What is
the end goal here? Striving to ensure that an app meet this interpretation, or
is it to deliver something of value to the stakeholders? If providing value to
the stakeholders requires use of *everything* standard, then that is what should
guide an implementation.
>
> Subbu
>

Any standardization effort would, in addition to defining the behavior
of application/atomcat+xml as a diff format, need to define a general
application/atomdiff+xml media type for general patching.  Consider
updating the atom:copyright of every Atom document in a system.  The
existing protocol interaction is GET-PUT, whereas this change could be
made using a much lighter-weight HEAD-PATCH interaction.  The new media
type would need to be extensible in the same way as Atom, while
limiting its scope by treating the contents of many elements as CDATA.

The point being, it's hard enough work to extend an existing media
type, let alone create a new one.  You may wind up having to develop
something else, in order to make a proposal, like I would have to do by
coming up with application/atomdiff+xml before I could get my desired
media type of applicaton/atomcat+xml standardized as a diff format to
PATCH Atom content.  Forging ahead without a standardization effort is
so much easier, that it constitutes an architectural cop-out in REST.

The Internet and the Web are wide-open due to standardization winning
out over proprietariness.  The REST style is not only derived from the
standardization process, it was also used to guide that process, and it
is meant to foster the ongoing wide-open nature of the Internet and the
Web by promoting the use of standard methods, media types, and link
relations over proprietary this-system-only designs -- since that's
what allowed the Web to flourish in the first place.  The crucible of
the Web made the REST style what it is, because that's what worked.

-Eric

Subbu Allamaraju wrote:
>
> On Dec 21, 2009, at 4:07 PM, Eric J. Bowman wrote:
>
> > Sure, this implementation is architecturally sound, but I have to
> > put up my asterisk stating that this portion of my API is not
> > standardized, and is therefore not REST.  Currently, by virtue of
> > Xforms 1.1 allowing
>

I also just wrote this:

"
Degrades my API to being a generic HTTP interface, as much as I may
wish to call it REST. Oh, it's architecturally sound and all, but the
REST style requires that standard media types be used for applying
method semantics, so this is clearly not the REST style, even though
PATCH is now officially part of the generic-interface-method club.
"

>
> I must say that this is an extreme interpretation. You are implying
> that any hint of non-standardness makes an app unRESTful. Not even
> the underlying standards of the web require such strict adherence.
>

We aren't talking about underlying standards, we're talking about an
architectural style that is based upon the use of an evolving set of
standard methods, media types and link relations.  I'm drawing a very
clear line of distinction between my 100% REST Atom Protocol system,
and its 0% REST tagging feature.  Standard Atom Protocol clients won't
see anything amiss, and will interoperate with the system to the best of
their abilities, but cannot see the system as a whole.  To participate
in the tagging activity requires the use of a nonstandard client.

I am harsher with my own work than I am with the work of others; I
don't see my overall API as RESTful because of the tagging feature, but
if someone else were to have implemented it, I wouldn't bother
bringing it up.  The key thing in REST is to optimize the hell out of
GET. If some non-REST feature isn't having any effect on GET
performance, then it doesn't really matter that much to the style
(although it may be critical to the goals of the system). PATCH traffic
is insignificant compared to GET traffic, so a nonstandard PATCH-based
feature can safely be suboptimal.

>
> Besides being questionable, such an interpretation is not very
> useful. What is the end goal here? Striving to ensure that an app
> meet this interpretation, or is it to deliver something of value to
> the stakeholders? If providing value to the stakeholders requires use
> of *everything* standard, then that is what should guide an
> implementation.
>

(Hypothetically speaking:) The end goal here is what differentiates the
system in a crowded field, the tagging feature.  The Domain Owner wants
a top-flight weblog and believes that this feature will help attract
Authors (by socializing the chore of tagging), Members (folks will only
sign up if there's something in it for them, like a new toy to play
with), and Nonmember Visitors (due to the quality of the content
provided by a community of regulars commenting on well-written
articles, drawn in by the differentiating features like social tagging).

The Internal Developers want something that any moron who can read a
spec can maintain, that provides a fundamentally sound platform on
which differentiating features may be created and modified in response
to user feedback.  They also understand that wide adoption by External
Developers of the protocol underlying the tagging feature, is crucial
to the success of that feature.  If a proprietary client is required to
use it, then it won't get very far.

The Internal Developers approach the Domain Owner and sell him on the
notion of a REST architecture based around Atom Protocol, due to REST's
scalability, efficiency, maintainability and serendipitous re-use.
Which is brought about primarily through the decoupling of client from
server provided by standard methods, media types and link relations...

Aren't the Internal Developers morally and ethically obligated at this
point, to inform the Domain Owner that the tagging feature is based on
a proprietary PATCH protocol, initially only be available via an Xforms
interface to users who download and install the necessary browser +
extension, unless External Developers create custom clients for it?
That it meets none of the goals of REST and therefore is a mismatch
with the style?  Isn't the success of this feature critical to the
project?

In order for the overall goals of the system to be met, the PATCH
extension to Atom Protocol must be standardized.  Only once it's
available as part of the standard libraries, will this system meet its
goals, which happen to overlap the goals of a REST architecture.  Until
then, any client of the tagging feature is coupled to a single server
implementation.

In order to succeed, the PATCH protocol must gain acceptance by being
implemented in other systems (even if the feature is different, say
auto-tagging instead of social tagging).  Only then will it succeed in
attracting the developers of existing Atom Protocol clients and
libraries.  Only then will it be a candidate standard.  Only then will
client be decoupled from server, through the shared understanding of the
evolution of an existing standard media type to encompass a new method.

It is absolutely essential that the non-RESTful nature of the PATCH
protocol be recognized before the implementation is even considered.
The Domain Owner is footing the bill, and must be able to make informed
decisions.  In this case, a decision to team with the Internal and
External Developers to create an open proposed standard to include this
protocol operation under the application/atom+xml umbrella would be
required for the project to succeed.  Otherwise, the nonstandard nature
of the key differentiating feature will be the project's Achilles' Heel.

Another possible decision, would be to modify existing open-source Atom
Protocol client code for the new protocol extension, offering pre-
compiled clients for different OSs on the website (putting back the
code, of course).  The worst decision would be to ignore the REST
mismatch and move on with a wholly proprietary API that breaks REST's
uniform interface. Like the early attempts at manned flight -- it might
take off, but it will never fly.

There are ways to overcome the limitations of nonstandard
implementations. But let's not pretend that not using standard media
types is somehow stylistically compatible with REST, when the benefits
of that style come from the decoupling of client and server that's only
possible _with_ standard media types.  Media types that exist for the
purpose of interacting with a single implementation, are fundamentally
at odds with the REST style.  My rule of thumb for creating media types
remains:  Don't!

-Eric

On Mon, 21 Dec 2009 11:53:59 -0500
Tim Williams wrote:
>
> My original contention was that 'calling DELETE' on some resource
> (URI) provided by the server, isn't 'going rogue' or violating the
> uniform interface even if it's not in the representation.  It may be
> met with a 405, but since "DELETE" is a part of the uniform interface
> between components in the system, I don't see how using it might be
> considered a violation of it.
>

Careful -- DELETE is a protocol-independent generic-interface method,
the HTTP implementation of which doesn't automatically result in a
uniform REST interface.  As with most methods.  My Xforms Atom Protocol
client, discussed here:

http://tech.groups.yahoo.com/group/rest-discuss/message/14260

Describes a uniform REST interface, and is in fact the only Atom
Protocol implementation I've seen that doesn't break the hypertext
constraint. However, the addition of PATCH:

http://tech.groups.yahoo.com/group/rest-discuss/message/14316

Degrades my API to being a generic HTTP interface, as much as I may
wish to call it REST.  Oh, it's architecturally sound and all, but the
REST style requires that standard media types be used for applying
method semantics, so this is clearly not the REST style, even though
PATCH is now officially part of the generic-interface-method club.

Let's take a closer look at PUT. HTTP (and FTP) assigns two different
semantics to PUT -- creation and replacement.  But, a REST API must
maintain consistent method semantics across all resources. Practically
speaking, the uniform interface constraint means your REST API must
limit PUT to one use or the other based on media type.

(Media types don't define method semantics {except in the case of a
media type which introduces a new method}, they describe the applied
semantics of existing methods.  This is why a custom media type cannot
apply partial-update semantics to PUT -- that would be redefining
method semantics rather than applying them.)

For example, Atom Protocol constrains PUT to replacement semantics,
while constraining POST to creation semantics.  Without changing the
semantics of the PUT or POST method, the application/atom+xml media
type describes the applied semantics of those HTTP methods, with the
goal of creating a uniform REST interface.  Any intermediary looking at
PUT or POST requests with the Atom media type knows the specific
semantics of the request, which cannot be known just by looking at the
protocol's generic method semantics.

Let's say you've implemented a standard Atom Protocol system, but now
you want to allow PUT to be used with a user-supplied URI to add items
into a collection without creating Atom media entries for them.

First of all, as with all use of PUT for file-upload applications, and
as Roy has pointed out, the hypertext constraint is broken.  Second, by
assigning a second semantic (create) to PUT for all resources _but_
application/atom+xml (replace), you have degraded your interface to the
status of generic HTTP.  A uniform REST interface requires that method
semantics be identical across all resources in the system, they MUST
NOT vary by media type or resource "type".

REST requires self-descriptive messaging.  This means it's the
combination of URI (includes protocol), request method, and *media
type* that determines the interface semantics.  Without including a
media type in a PUT request, how is an HTTP intermediary to determine
whether the semantics are creation or replacement?  That isn't very
self-descriptive.  Whereas, if the media type is application/atom+xml,
it's clear to the entire world that the interaction semantics are
replacement, not creation, as specified by the media type.

This brings us back to DELETE, which, believe it or not, also has two
different semantics in HTTP.  WebDAV extends DELETE to include a
'Depth' header, in the absence of which all members of a collection are
deleted along with the collection.  Otherwise, HTTP DELETE is meant to
remove a single resource.  There are two paradigms at cross-purpose
here, one is Web as Filesystem and the other is Web As It Exists.

Since a Web collection may be a transitory thing, say the top-5 most-
commented posts on a weblog, the elimination of all members if it's
deleted to make way for a top-10 list would be undesirable.  Or, the
resource may literally map to a filesystem, in which case all members
must be deleted before a collection may be removed.  Either way is
supported in a generic interface.  Only one way or the other is allowed
(per protocol) in a uniform interface.

Atom Protocol skipped the debate entirely, by deciding to allow DELETE
on collections without defining the semantics.  Feature, or bug?  You
decide...  The Atom media type could have opted to define WebDAV
semantics to a collection DELETE, in which case transitory Atom
Protocol collections wouldn't be practical, or gone the other way and
defined it as only removing the collection feed, in which case the
folks wanting to do bulk-delete with one request would be unhappy.

So yes, a REST API must rely on media types to determine the semantics
of protocol methods.  Using HTTP DELETE on a resource represented only
as text/html isn't RESTful now, but it may become so once HTML 5 has
added (hopefully at least) PUT and DELETE into the text/html realm, at
which point they can be hypertext-driven. The other solution is to use
FTP DELETE, since that protocol doesn't care about media type and won't
allow collection-delete.  But this only works if you're following the
filesystem paradigm and don't care about the hypertext constraint.

You can't use FTP DELETE to remove a negotiated resource, since it
isn't really there on the filesystem, so you'd have to use HTTP DELETE
-- but which semantic?  Remove just the negotiated resource, or remove
all variants first?  Or use MDELETE from WebDAV or FTP?  While there
are multiple methods and semantics from multiple protocols to achieve
deletion, the REST style isn't free-form, your design choices must be
encompassed within standard media types.

The Xforms solution allows any choice to be hypertext-driven, so
creating a system using the standard application/xhtml+xml media type
is my first choice, transformed from some other variant, and presented
at a negotiated URL. The media type allows any DELETE functionality to
be defined in-band for the entire resource, or targeted at some other
resource, using the hypertext constraint while preserving the uniform
REST interface (if implemented properly, of course).

If an Atom entry is one variant in a negotiated resource, and the other
is HTML, the resource may be deleted outright because the Atom media
type specifically allows DELETE to remove the member resource (even
without hypertext), making it only logical to also DELETE the derived
HTML variant.  Sorry to complicate things by pointing out that you can't
just DELETE willy-nilly in REST, but...

-Eric

On Dec 21, 2009, at 4:07 PM, Eric J. Bowman wrote:

> Sure, this implementation is architecturally sound, but I have to put
> up my asterisk stating that this portion of my API is not standardized,
> and is therefore not REST.  Currently, by virtue of Xforms 1.1 allowing

I must say that this is an extreme interpretation. You are implying that any
hint of non-standardness makes an app unRESTful. Not even the underlying
standards of the web require such strict adherence.

Besides being questionable, such an interpretation is not very useful. What is
the end goal here? Striving to ensure that an app meet this interpretation, or
is it to deliver something of value to the stakeholders? If providing value to
the stakeholders requires use of *everything* standard, then that is what should
guide an implementation.

Subbu

"Eric J. Bowman" wrote:
>
> "swschilke" wrote:
> >
> > I wonder which was the "first" paper on CRUD and the first paper
> > which brought CRUD and REST togehter? The dissertation of Dr.
> > Fielding maybe?
> >
>
> The thesis makes no mention of CRUD, and Roy is on record stating that
> REST has nothing to do with CRUD.
>

But this doesn't mean you can't RESTfully map CRUD to HTTP.  Atom
Protocol is basically a CRUD implementation.  My extension to it, here:

http://tech.groups.yahoo.com/group/rest-discuss/message/14316

Basically implements CRUUD, where the first 'U' means whole update via
replacement, while the second 'U' means partial update via diff.

-Eric

"Eric J. Bowman" wrote:
>
> So my client extends Atom Protocol by self-describing the unspecified
> behavior of DELETE on a collection, in two different user-selectable
> ways, using hypertext to drive application state and avoiding Atom
> Protocol's REST mismatch on DELETE for both collections and member
> resources.  Client and server are now decoupled, and may evolve
> independently.
>

My system also extends Atom Protocol through the use of PATCH.  The
system is a basic weblog, with multiple authors, plus registered and
unregistered users.  Role-based security is implemented (using HTTP-
Digest) per HTTP method:  Authors may POST new articles and PUT
edits to their own articles.  Registered users may POST new comments
and, for a limited time, PUT edits to their own comments.  Unregistered
users may POST comments.  Only Administrator-authors may DELETE
anything.

What I want, is for authors and registered users to be able to change
the tags associated with an article.  If I follow Atom Protocol and do
this with PUT, then I'm breaking my security model by allowing any
author or registered user to potentially edit the article, unless I add
a whole lot of code to the server.  This would also require much more
bandwidth than necessary, since the client only wants to update the
<category/> tags.  So I define application/atomcat+xml as one possible
delta format for application/atom+xml representations, and implement
PATCH.

Now, my security model remains intact, as I have a new method to
secure, which only allows the <category/> tags to be changed.  This
will flesh out to where the server returns 202 Accepted with a message
indicating that the server keeps track of all submitted PATCH entities
associated with the article, and calculates the Top 5 tags, which then
become the actual tags for an article.  So a PATCH request may or may
not honor the user's intention, and is not limited to only suggesting
five tags.  Without all that, a PATCH adds new tags by virtue of their
presence, while removing old tags by virtue of their absence, in the
submitted application/atomcat+xml document.

Sure, this implementation is architecturally sound, but I have to put
up my asterisk stating that this portion of my API is not standardized,
and is therefore not REST.  Currently, by virtue of Xforms 1.1 allowing
any HTTP method to be used, PATCH is only defined for application/xhtml
+xml.  Its use is not defined by the media types I'm using, as
application/atomcat+xml doesn't define itself as a possible delta
format (even though it can be), and application/atom+xml only defines
GET, PUT, POST and DELETE (and HEAD, as a given any time GET is
allowed).

So how do I change my Implementation to make it REST?  Well, I don't.
The problem lies with my Model.  However, the (re)standardization of
PATCH recently makes it inevitable that Atom Protocol will eventually
be revised -- PATCH only didn't make the cut because it wasn't "in"
HTTP (even though it was).  Now that that's been cleared up, there's no
reason to avoid PATCH in Atom Protocol (not suggesting this will happen
any time soon, though).

When the time comes to add PATCH to Atom Protocol, it will be possible
to base that standardization on existing implementations.  If my use
makes the cut, I can change my Model to follow the new standard, instead
of going off the reservation.  My Implementation wouldn't need to be
changed, but it would become RESTful.  Until then, it's proprietary,
even if it's open-source, from the REST perspective.

-Eric

On Dec 22, 2009, at 12:11 AM, Roger Gonzalez wrote:

> mike amundsen wrote:
>> you build clients based on the media type.
> Any given resource may have multiple representations that have
> exactly the same media type; for example, an image resource may have
> an image/png representing the full content as well as an image/png
> representing a thumbnail.  Content negotiation based only on media
> type isn't sufficient.
>

These representations should be available at different resources
because they are different things. I'd use:


/foo/images/6676
/foo/images/6676?view=thumbnail

Then conneg works fine on both.

Jan


> -rg
>

--------------------------------------
Jan Algermissen

Mail: algermissen@...
Blog: http://algermissen.blogspot.com/
Home: http://www.jalgermissen.com
--------------------------------------

On Dec 21, 2009, at 11:47 PM, Noah Campbell wrote:

>
>
> "This would lead to "If you are going to adopt REST with all the
> benefits do it all the way through and believe that the business
> level harm occasionally done by evolution costs far less than
> running a SOAP architecture in the long run."
>
> Basically, no.  If your notion that SOAP somehow solved the problems
> that you've identified being an issue in REST then I'm curious how
> you over came SOAP's shortcoming's.  If anything, SOAP is more rigid
> and this leads to increase cost in the face of change.  This has
> nothing to do with SOAP the architecture, but more SOAP the
> implementation.  WSDL has done more harm than good, IMO.  I've seen
> POX work really well, but again it's a different architecture than
> REST.
>
> I'm curious how SLA enforcement is achieved with a SOAP architecture?


That is simple with SOAP because the artifact to enforce is the API.
The SLA would be around the API lifecycle (e.g. once an API is out, it
has to persist for three years). Not saying that the API is a
sufficient means to guarantee stability but it expresses a fixed
contract. WS-* simply excludes evolution without explicit versioning
(doo, hope that is really correct; not an expert there). The SLA would
only be violated if an existing API would go away. The evolution issue
is done away with by tightly coupling the components.

(AFAIK anyway)

Jan


>
> -Noah
>
> On Mon, Dec 21, 2009 at 1:18 PM, Jan Algermissen <algermissen1971@...
> > wrote:
> Noah,
>
> (see below),
>
>
> On Dec 21, 2009, at 8:19 PM, Noah Campbell wrote:
>
> "AtomPub for example enables the client *implementor* to assume that
> a GET on a collection will return an Atom feed document."
>
> To your prior point, something is broken, but what?  Is it the
> architectural style (by asking it on this mailing list it may be
> that you think it is)?  Is it the transport HTTP?  Is it the
> specification?  Is it the implementor of the server or the client?
> Is it something else?
>
> You focus on the assumption being negative and rightly so, but lets
> be formal about what an assumption is.  You've alluded to an
> assumption not met as negative.
>
> I is usually not that negative on the open Web because the overall
> expectations are not that strict; people allways plan for any kinds
> of changes to happen and REST advantage here is that the uniform
> interface enables the communication (the talking to each other) to
> succeed even if there is an error. Instead of everything falling
> apart the client user or developer can pick up the clue (e.g. the
> 406 body) and follow her nose to fix things.
>
> But this is a model that is very hard to sell inside the enterprise
> because the business level contracts require a certain degree of
> certainty (e.g. SLAs). Saying "hey, if business transactions
> suddenly stop working, look at the lock file and see what the
> service owner suggested as a fix. Nah, this will not happen evry
> often, just be prepared for it in any case".
>
> OTH, it might be the price to pay for the evolvability extreme of
> not needing any kind of out of band communication between client and
> server developer at all. Possibly, if you compare investment in time
> and travel resources etc. involved in discussing interfaces of the
> SOAP style with the cost of some missing transactions it might even
> make a compelling case. (Like airline rather pay customers some
> money for overbooked flights than to make sure that every passenger
> definitely gets a seat. The latter just costs less).
>
> This would lead to "If you are going to adopt REST with all the
> benefits do it all the way through and believe that the business
> level harm occasionally done by evolution costs far less than
> running a SOAP architecture in the long run.
>
>
> If I had to translate this into code it would look like this:
>
> fread (buffer, 1, lSize, pFile)
>
> There is an assumption here given all the variables are initialized
> correctly.  Do you see it?
>
> The return value is not checked.  The read may not have read all the
> data in the file in this particular call.  Who is the guilty party?
> Is it the architecture, POSIX?  Is it the
specification,http://www.cplusplus.com/reference/clibrary/cstdio/fread/?
>  Is it the implementation, GNU? Is it the implementor?  I'd argue
> it's the implementor.  C has a long established history of using
> return values to indicate success (as well as return values...but
> errno provides a (kludgy?) workaround).
>
> I would urge an implementer to understand the architecture style,
> the specification, the implementation and focus very hard on making
> sure assumptions like the above are not scattered through out the
> code.  Since REST is about two remote systems communicating, I'd
> argue that any client must validate any assumption before
> proceeding, including checking the error code.  If not, the client
> will be be brittle, prone to error, and cost more in ongoing
> maintenance.  Good, robust applications assume nothing.
>
> Let's assume for a moment the AtomPub spec represents the typical
> spec for a service.  It assumes RESTful architectural style using
> the HTTP transport.  To your point, the service must behave has
> specified for any goal to be obtained.   Aspects of the http
> transport "leak" into the interaction even those it has not been
> specified.  The spec doesn't call out all the different response
> codes and how to handle them, it relies on those familiar with the
> HTTP transport to deal with those gracefully.  Case in point, if you
> do:
>
> GET /
> Accept: application/atomsvc+xml
>
> and get a
>
> 307: Moved Temporarily
> Location: /svc.atom
>
> or
>
> 305: Use Proxy
> Location: /proxy/svc.atom
>
> or
>
> 401: Unauthorized
> www-authenticate: basic
>
> Is this an error?
>
> Roy thesis doesn't explicitly say yes or no.  However, the argument
> for a uniform interface is that the intermediary can participate
> without affecting the remote call.  I'll extrapolate a little in
> that a uniform interface provides a common behavior that permeates
> all levels of an architecture, including the implementation.  The
> testers should be not be surprised to see the 3 response outline
> above and should be able to accommodate appropriately.
>
>
> Agreed and I see your point. But (sorry :-) I'd expect an HTTP
> client connector to be able to follow these redirects or
> authenticate on its own without even propagating it to the next
> level. Most client connectors do so (depending on config of course).
> So, I'd limit what we are talking about to steady states and leave
> out the transient ones.
>
> However, I understand you to say that an AtomPub client
> implementation that uses an HTTP client connector must of course
> implement all of HTTP. And yes, I agree that the 406 must be handled
> correctly. But then? there is no possible recovery from the broken
> expectation to receive an Atom feed.
>
>
>
> Hopefully this response helps move the discussion forward :)
>
> Thanks for keeping up with this. I am just sorry that I seem to be
> so unable to get this accross.
>
> Jan
>
>
>
>
> -Noah
>
> On Mon, Dec 21, 2009 at 4:35 AM, Jan Algermissen <algermissen1971@...
> > wrote:
>
> On Dec 21, 2009, at 1:25 PM, Jorn Wildt wrote:
>
> > Oh, lets backtrack a bit. You said earlier on:
> >
> >> In the enterprise people want to develop clients and services in
> >> parallel, shich rules out client design by inspecting the runtime
> >> behavior of a service.
> >
> > Then I said: you need not expect at runtime, you can have a mock. To
> > this you answered: no, you build clients on specs.
> >
> > What I was trying to say was: if you build clients on specs and RFC
> > 5023 (application/atomsrv+xml) is a spec, then what is keeping you
> > from building any kind of REST client on similar specs for other
> > media types? If both server and client agrees on the media type spec
> > then both can be built individually and simultaneously.
>
>
> No, that is all fine and I agree. I am questioning the RESTfulness of
> specs that allow the clients to make assumptions about the hypermedia
> it will receive at some point in the interaction. AtomPub for example
> enables the client *implementor* to assume that a GET on a collection
> will return an Atom feed document. This is equivalent to making an
> assumption about the application state to be in after the GET to the
> collection.
>
> And I am trying to say that M2M clients (besides passibe, server
> driven crawlers) can only be built when such contracts are in place.
>
> Jan
>
>
> >
> > /Jørn
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>
> --------------------------------------
> Jan Algermissen
>
> Mail: algermissen@...
> Blog: http://algermissen.blogspot.com/
> Home: http://www.jalgermissen.com
> --------------------------------------
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>
> --------------------------------------
> Jan Algermissen
>
> Mail: algermissen@...
> Blog: http://algermissen.blogspot.com/
> Home: http://www.jalgermissen.com
> --------------------------------------
>
>
>
>
>
>
>

--------------------------------------
Jan Algermissen

Mail: algermissen@...
Blog: http://algermissen.blogspot.com/
Home: http://www.jalgermissen.com
--------------------------------------

Noah,

umm, I tried to say the opposite than you understood. What I meant is
that if you really adopt REST you should do it in the same fashion as
it works on the open Web (including an occasional 406 for example).
The cost of the system not running until you fixed the clients to
catch up with the (rare but possible) unexpected server evolution
should be less than the overall additional cost of adopting a WS-*
like technology.

IOW, REST is economically cheaper than SOAP even if you embrace the
occasional problems[1] resulting from truly uncoupled components.

[1] 'Problem' meaning: a communication problem based on the client
being a machine, not a human.

Jan



On Dec 21, 2009, at 11:47 PM, Noah Campbell wrote:

> "This would lead to "If you are going to adopt REST with all the
> benefits do it all the way through and believe that the business
> level harm occasionally done by evolution costs far less than
> running a SOAP architecture in the long run."
>
> Basically, no.  If your notion that SOAP somehow solved the problems
> that you've identified being an issue in REST then I'm curious how
> you over came SOAP's shortcoming's.  If anything, SOAP is more rigid
> and this leads to increase cost in the face of change.  This has
> nothing to do with SOAP the architecture, but more SOAP the
> implementation.  WSDL has done more harm than good, IMO.  I've seen
> POX work really well, but again it's a different architecture than
> REST.
>
> I'm curious how SLA enforcement is achieved with a SOAP architecture?
>
> -Noah
>
> On Mon, Dec 21, 2009 at 1:18 PM, Jan Algermissen <algermissen1971@...
> > wrote:
> Noah,
>
> (see below),
>
>
> On Dec 21, 2009, at 8:19 PM, Noah Campbell wrote:
>
> "AtomPub for example enables the client *implementor* to assume that
> a GET on a collection will return an Atom feed document."
>
> To your prior point, something is broken, but what?  Is it the
> architectural style (by asking it on this mailing list it may be
> that you think it is)?  Is it the transport HTTP?  Is it the
> specification?  Is it the implementor of the server or the client?
> Is it something else?
>
> You focus on the assumption being negative and rightly so, but lets
> be formal about what an assumption is.  You've alluded to an
> assumption not met as negative.
>
> I is usually not that negative on the open Web because the overall
> expectations are not that strict; people allways plan for any kinds
> of changes to happen and REST advantage here is that the uniform
> interface enables the communication (the talking to each other) to
> succeed even if there is an error. Instead of everything falling
> apart the client user or developer can pick up the clue (e.g. the
> 406 body) and follow her nose to fix things.
>
> But this is a model that is very hard to sell inside the enterprise
> because the business level contracts require a certain degree of
> certainty (e.g. SLAs). Saying "hey, if business transactions
> suddenly stop working, look at the lock file and see what the
> service owner suggested as a fix. Nah, this will not happen evry
> often, just be prepared for it in any case".
>
> OTH, it might be the price to pay for the evolvability extreme of
> not needing any kind of out of band communication between client and
> server developer at all. Possibly, if you compare investment in time
> and travel resources etc. involved in discussing interfaces of the
> SOAP style with the cost of some missing transactions it might even
> make a compelling case. (Like airline rather pay customers some
> money for overbooked flights than to make sure that every passenger
> definitely gets a seat. The latter just costs less).
>
> This would lead to "If you are going to adopt REST with all the
> benefits do it all the way through and believe that the business
> level harm occasionally done by evolution costs far less than
> running a SOAP architecture in the long run.
>
>
> If I had to translate this into code it would look like this:
>
> fread (buffer, 1, lSize, pFile)
>
> There is an assumption here given all the variables are initialized
> correctly.  Do you see it?
>
> The return value is not checked.  The read may not have read all the
> data in the file in this particular call.  Who is the guilty party?
> Is it the architecture, POSIX?  Is it the specification,
http://www.cplusplus.com/reference/clibrary/cstdio/fread/?
>  Is it the implementation, GNU? Is it the implementor?  I'd argue
> it's the implementor.  C has a long established history of using
> return values to indicate success (as well as return values...but
> errno provides a (kludgy?) workaround).
>
> I would urge an implementer to understand the architecture style,
> the specification, the implementation and focus very hard on making
> sure assumptions like the above are not scattered through out the
> code.  Since REST is about two remote systems communicating, I'd
> argue that any client must validate any assumption before
> proceeding, including checking the error code.  If not, the client
> will be be brittle, prone to error, and cost more in ongoing
> maintenance.  Good, robust applications assume nothing.
>
> Let's assume for a moment the AtomPub spec represents the typical
> spec for a service.  It assumes RESTful architectural style using
> the HTTP transport.  To your point, the service must behave has
> specified for any goal to be obtained.   Aspects of the http
> transport "leak" into the interaction even those it has not been
> specified.  The spec doesn't call out all the different response
> codes and how to handle them, it relies on those familiar with the
> HTTP transport to deal with those gracefully.  Case in point, if you
> do:
>
> GET /
> Accept: application/atomsvc+xml
>
> and get a
>
> 307: Moved Temporarily
> Location: /svc.atom
>
> or
>
> 305: Use Proxy
> Location: /proxy/svc.atom
>
> or
>
> 401: Unauthorized
> www-authenticate: basic
>
> Is this an error?
>
> Roy thesis doesn't explicitly say yes or no.  However, the argument
> for a uniform interface is that the intermediary can participate
> without affecting the remote call.  I'll extrapolate a little in
> that a uniform interface provides a common behavior that permeates
> all levels of an architecture, including the implementation.  The
> testers should be not be surprised to see the 3 response outline
> above and should be able to accommodate appropriately.
>
>
> Agreed and I see your point. But (sorry :-) I'd expect an HTTP
> client connector to be able to follow these redirects or
> authenticate on its own without even propagating it to the next
> level. Most client connectors do so (depending on config of course).
> So, I'd limit what we are talking about to steady states and leave
> out the transient ones.
>
> However, I understand you to say that an AtomPub client
> implementation that uses an HTTP client connector must of course
> implement all of HTTP. And yes, I agree that the 406 must be handled
> correctly. But then? there is no possible recovery from the broken
> expectation to receive an Atom feed.
>
>
>
> Hopefully this response helps move the discussion forward :)
>
> Thanks for keeping up with this. I am just sorry that I seem to be
> so unable to get this accross.
>
> Jan
>
>
>
>
> -Noah
>
> On Mon, Dec 21, 2009 at 4:35 AM, Jan Algermissen <algermissen1971@...
> > wrote:
>
> On Dec 21, 2009, at 1:25 PM, Jorn Wildt wrote:
>
> > Oh, lets backtrack a bit. You said earlier on:
> >
> >> In the enterprise people want to develop clients and services in
> >> parallel, shich rules out client design by inspecting the runtime
> >> behavior of a service.
> >
> > Then I said: you need not expect at runtime, you can have a mock. To
> > this you answered: no, you build clients on specs.
> >
> > What I was trying to say was: if you build clients on specs and RFC
> > 5023 (application/atomsrv+xml) is a spec, then what is keeping you
> > from building any kind of REST client on similar specs for other
> > media types? If both server and client agrees on the media type spec
> > then both can be built individually and simultaneously.
>
>
> No, that is all fine and I agree. I am questioning the RESTfulness of
> specs that allow the clients to make assumptions about the hypermedia
> it will receive at some point in the interaction. AtomPub for example
> enables the client *implementor* to assume that a GET on a collection
> will return an Atom feed document. This is equivalent to making an
> assumption about the application state to be in after the GET to the
> collection.
>
> And I am trying to say that M2M clients (besides passibe, server
> driven crawlers) can only be built when such contracts are in place.
>
> Jan
>
>
> >
> > /Jørn
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>
> --------------------------------------
> Jan Algermissen
>
> Mail: algermissen@...
> Blog: http://algermissen.blogspot.com/
> Home: http://www.jalgermissen.com
> --------------------------------------
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>
> --------------------------------------
> Jan Algermissen
>
> Mail: algermissen@...
> Blog: http://algermissen.blogspot.com/
> Home: http://www.jalgermissen.com
> --------------------------------------
>
>
>
>

--------------------------------------
Jan Algermissen

Mail: algermissen@...
Blog: http://algermissen.blogspot.com/
Home: http://www.jalgermissen.com
--------------------------------------

On Dec 21, 2009, at 10:18 PM, Jan Algermissen wrote:

> (Like airline rather pay customers some money
> for overbooked flights than to make sure that every passenger
> definitely gets a seat. The latter just costs less).

s/latter/former/

Jan

Noah,

(see below),

On Dec 21, 2009, at 8:19 PM, Noah Campbell wrote:

> "AtomPub for example enables the client *implementor* to assume that
> a GET on a collection will return an Atom feed document."
>
> To your prior point, something is broken, but what?  Is it the
> architectural style (by asking it on this mailing list it may be
> that you think it is)?  Is it the transport HTTP?  Is it the
> specification?  Is it the implementor of the server or the client?
> Is it something else?
>
> You focus on the assumption being negative and rightly so, but lets
> be formal about what an assumption is.  You've alluded to an
> assumption not met as negative.

I is usually not that negative on the open Web because the overall
expectations are not that strict; people allways plan for any kinds of
changes to happen and REST advantage here is that the uniform
interface enables the communication (the talking to each other) to
succeed even if there is an error. Instead of everything falling apart
the client user or developer can pick up the clue (e.g. the 406 body)
and follow her nose to fix things.

But this is a model that is very hard to sell inside the enterprise
because the business level contracts require a certain degree of
certainty (e.g. SLAs). Saying "hey, if business transactions suddenly
stop working, look at the lock file and see what the service owner
suggested as a fix. Nah, this will not happen evry often, just be
prepared for it in any case".

OTH, it might be the price to pay for the evolvability extreme of not
needing any kind of out of band communication between client and
server developer at all. Possibly, if you compare investment in time
and travel resources etc. involved in discussing interfaces of the
SOAP style with the cost of some missing transactions it might even
make a compelling case. (Like airline rather pay customers some money
for overbooked flights than to make sure that every passenger
definitely gets a seat. The latter just costs less).

This would lead to "If you are going to adopt REST with all the
benefits do it all the way through and believe that the business level
harm occasionally done by evolution costs far less than running a SOAP
architecture in the long run.

> If I had to translate this into code it would look like this:
>
> fread (buffer, 1, lSize, pFile)
>
> There is an assumption here given all the variables are initialized
> correctly.  Do you see it?
>
> The return value is not checked.  The read may not have read all the
> data in the file in this particular call.  Who is the guilty party?
> Is it the architecture, POSIX?  Is it the specification,
http://www.cplusplus.com/reference/clibrary/cstdio/fread/?
>  Is it the implementation, GNU? Is it the implementor?  I'd argue
> it's the implementor.  C has a long established history of using
> return values to indicate success (as well as return values...but
> errno provides a (kludgy?) workaround).
>
> I would urge an implementer to understand the architecture style,
> the specification, the implementation and focus very hard on making
> sure assumptions like the above are not scattered through out the
> code.  Since REST is about two remote systems communicating, I'd
> argue that any client must validate any assumption before
> proceeding, including checking the error code.  If not, the client
> will be be brittle, prone to error, and cost more in ongoing
> maintenance.  Good, robust applications assume nothing.
>
> Let's assume for a moment the AtomPub spec represents the typical
> spec for a service.  It assumes RESTful architectural style using
> the HTTP transport.  To your point, the service must behave has
> specified for any goal to be obtained.   Aspects of the http
> transport "leak" into the interaction even those it has not been
> specified.  The spec doesn't call out all the different response
> codes and how to handle them, it relies on those familiar with the
> HTTP transport to deal with those gracefully.  Case in point, if you
> do:
>
> GET /
> Accept: application/atomsvc+xml
>
> and get a
>
> 307: Moved Temporarily
> Location: /svc.atom
>
> or
>
> 305: Use Proxy
> Location: /proxy/svc.atom
>
> or
>
> 401: Unauthorized
> www-authenticate: basic
>
> Is this an error?
>
> Roy thesis doesn't explicitly say yes or no.  However, the argument
> for a uniform interface is that the intermediary can participate
> without affecting the remote call.  I'll extrapolate a little in
> that a uniform interface provides a common behavior that permeates
> all levels of an architecture, including the implementation.  The
> testers should be not be surprised to see the 3 response outline
> above and should be able to accommodate appropriately.
>

Agreed and I see your point. But (sorry :-) I'd expect an HTTP client
connector to be able to follow these redirects or authenticate on its
own without even propagating it to the next level. Most client
connectors do so (depending on config of course). So, I'd limit what
we are talking about to steady states and leave out the transient ones.

However, I understand you to say that an AtomPub client implementation
that uses an HTTP client connector must of course implement all of
HTTP. And yes, I agree that the 406 must be handled correctly. But
then? there is no possible recovery from the broken expectation to
receive an Atom feed.


> Hopefully this response helps move the discussion forward :)

Thanks for keeping up with this. I am just sorry that I seem to be so
unable to get this accross.

Jan


>
> -Noah
>
> On Mon, Dec 21, 2009 at 4:35 AM, Jan Algermissen <algermissen1971@...
> > wrote:
>
> On Dec 21, 2009, at 1:25 PM, Jorn Wildt wrote:
>
> > Oh, lets backtrack a bit. You said earlier on:
> >
> >> In the enterprise people want to develop clients and services in
> >> parallel, shich rules out client design by inspecting the runtime
> >> behavior of a service.
> >
> > Then I said: you need not expect at runtime, you can have a mock. To
> > this you answered: no, you build clients on specs.
> >
> > What I was trying to say was: if you build clients on specs and RFC
> > 5023 (application/atomsrv+xml) is a spec, then what is keeping you
> > from building any kind of REST client on similar specs for other
> > media types? If both server and client agrees on the media type spec
> > then both can be built individually and simultaneously.
>
>
> No, that is all fine and I agree. I am questioning the RESTfulness of
> specs that allow the clients to make assumptions about the hypermedia
> it will receive at some point in the interaction. AtomPub for example
> enables the client *implementor* to assume that a GET on a collection
> will return an Atom feed document. This is equivalent to making an
> assumption about the application state to be in after the GET to the
> collection.
>
> And I am trying to say that M2M clients (besides passibe, server
> driven crawlers) can only be built when such contracts are in place.
>
> Jan
>
>
> >
> > /Jørn
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>
> --------------------------------------
> Jan Algermissen
>
> Mail: algermissen@...
> Blog: http://algermissen.blogspot.com/
> Home: http://www.jalgermissen.com
> --------------------------------------
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

--------------------------------------
Jan Algermissen

Mail: algermissen@...
Blog: http://algermissen.blogspot.com/
Home: http://www.jalgermissen.com
--------------------------------------

On Dec 21, 2009, at 5:46 PM, alistair.miles wrote:

> Hi Jan,
>
> Forgive me, but I've been squinting your activity diagram [1] and
> trying to figure out how that maps onto a sequence of REST
> interactions. E.g., can each message passing from buyer to seller be
> mapped onto an HTTP request, and each message from seller to buyer
> an HTTP response? Or am I completely misunderstanding the intention
> of the diagram?

My intention was to provide an example of how you can place object
nodes on the swim lanes to visualize the payload. I did not mean to
point you to the collaboration actually shown in that diagram. (It is
not a RESTstyle interaction but message passing with fixed endpoints -
other story anyway).

In my diarams I show each HTTP message as an object node. Request and
response.


>
> I'm interested because I've been trying to figure out the best
> conventions for diagramming workflow that map cleanly onto a
> hypermedia / REST service design. Your activity diagram is quite
> different from the type of state transition diagrams used in [2].

Those are state diagrams, showing the current's client application
state. That is another thing you could model that I forgot to mention.
Beware though, that this is also never a design artifact but a runtime
example (since the actual state machine is not known at design time -
it is discovered at run time).


> Maybe I shouldn't be trying to compare [1] and [2] because they're
> trying to model different aspects of the system? Sorry, thinking out
> loud...

See previous sentence.

Jan

>
> Thanks,
>
> Alistair.
>
> [1] http://docs.oasis-open.org/ubl/cs-UBL-2.0/art/UBL-2.0-OrderingProcess.jpg
> [2] http://www.infoq.com/articles/webber-rest-workflow
>
> --- In rest-discuss@yahoogroups.com, Jan Algermissen
> <algermissen1971@...> wrote:
>>
>>
>> On Dec 21, 2009, at 11:56 AM, swschilke wrote:
>>
>>> Dear Everbody,
>>>
>>> you are such a valuable resource for knowledge about REST that I
>>> apologize to bother you with my questions:
>>
>> No need to apologize - that is the purpose of this list.
>>
>>>
>>> What would you recommend to visualize REST (WADL) architectures?
>>> I've read some papers proposing extensions e.g., to UML, but I am
>>> open to recommendations (worst case I use Powerpoint).
>>
>> What do you intend to visualize? Design artifacts? or Runtime
>> examples? Or server side implementation aspects?
>>
>> As for design artifacts: since with REST all design is done by
>> specifying hypermedia there is not really much you can visualize
>> regarding design time.
>>
>> For runtime examples I use UML activity diagrams with swim lanes,
>> placing the messages as object nodes on the lanes (see the UBL
>> docs[1]
>> as an example).
>>
>> For server side implementation class diagrams are a good choice,
>> making each resource a class.
>>
>>
>> HTH,
>>
>> Jan
>>
>>
>> [1] http://docs.oasis-open.org/ubl/cs-UBL-2.0/art/UBL-2.0-OrderingProcess.jpg
>>
>>
>>>
>>> Kind regards and thank you very much
>>>
>>> sws
>>>
>>>
>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>
>> --------------------------------------
>> Jan Algermissen
>>
>> Mail: algermissen@...
>> Blog: http://algermissen.blogspot.com/
>> Home: http://www.jalgermissen.com
>> --------------------------------------
>>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

--------------------------------------
Jan Algermissen

Mail: algermissen@...
Blog: http://algermissen.blogspot.com/
Home: http://www.jalgermissen.com
--------------------------------------

On 11 Dec 2009, at 01:41, Solomon Duskis wrote:

> These seem like great examples of RDF and semantic web data linked data.  I
> definitely will be looking into it. However, I'm not quite sure how that
> would apply to a business scenario which includes both linked data and
> operations and work flow.

There is the GoodRelations ontology

     http://purl.org/goodrelations/

which should start finding a lot of very useful applications. I have not been
following it but I think it has been used by BestBuy now, and does some
interesting things in Google Search results

     http://www.ebusiness-unibw.org/wiki/GoodRelationsInGoogle


> What's the sweet spot for RDF?  What rules of thumb would you use to choose
> RDF vs. ATOM vs. XML/JSon API alternatives?

There is already a confusion in your question: you first need to distinguish
between syntax and semantics. RDF is about semantics, done on a global scale
with URIs.

Here is a picture describing the relation between syntax and semantics

     http://blogs.sun.com/bblfish/entry/the_limitations_of_json

The format to serialise it in is a secondary problem, and there are a lot
available. In fact any XML format can be seen as an RDF format with  GRDDL . The
advantage of the native formats is that once you have defined your vocabulary,
you no longer need to worry about the formats again! That is one big advantage.

The next is that you can mix vocabularies, so you don't have to keep reinventing
names for things.

Third: you can find the meaning of a term (URLs in a linked data environment) by
clicking on it.  (Just like you do on the web).

      http://blogs.sun.com/bblfish/entry/get_my_meaning

So the above reasons make it simpler to develop and use applications. That means
the people seeing your RDF will be able to quickly work out how it fits with
their needs, what you are saying.

Finally it just simple REST. On a global medium like the web you can ONLY use
URIs to refer to things. So you might as well think that way from the start. If
you don't do it, it is because you have not yet broken out of client/server
thinking.

Henry


>
> -Solomon
>
> On Thu, Dec 10, 2009 at 7:29 PM, Story Henry <henry.story@...>wrote:
>
>>
>>
>>
>> On 26 Nov 2009, at 20:45, swschilke wrote:
>>
>>> Dear *,
>>>
>>> can you kindly point me out some good examples of REST implementations.
>> Preferable well documented ;-) - I've read the O'Reilly book about the
>> Twitter API but I want to see more.
>>
>> Try http://dbpedia.org and the growing Linked Data space
>> http://linkeddata.org/
>>
>> Henry
>>
>>> Kind regards
>>>
>>>
>>> sws
>>>

"swschilke" wrote:
>
> I wonder which was the "first" paper on CRUD and the first paper
> which brought CRUD and REST togehter? The dissertation of Dr.
> Fielding maybe?
>

The thesis makes no mention of CRUD, and Roy is on record stating that
REST has nothing to do with CRUD.

-Eric

On Dec 21, 2009, at 6:23 PM, Noah Campbell wrote:

> "But this means that it is ok for the server to break it's own
> promise:
> AtomPub says a feed will be available. And it is still ok for the
> server to send me a 406?"
>
> I'm not sure how this is breaking it's promise?

Just saw that AtomPub even says this:
"For example, although this specification only defines the expected
behavior of Collections with respect to GET and POST, this does not
imply that PUT, DELETE, PROPPATCH, and others are forbidden on
Collection Resources" [1]
AtomPub says that it "defines the expected behavior of Collections
with respect to GET and POST" which is then provided in section 5. Is
that not defining expectations that client developers use to implement
AtomPub clients?
If these expectations are not met by the server then, yes, the server
is breaking the contract established by RFC 5023.
Jan
[1] http://tools.ietf.org/html/rfc5023#section-4.4



> Don't forget that the response codes are part of the standard
> interface and contract with the client.  While not specific to REST
> (i.e. HTTP is one implementation) the concept of uniform interface
> is.  I think that many people focus on the verbs (GET, PUT, POST,
> DELETE) while very little attention is given to the plethora of
> response codes.  Atompub definitely brought 201 Created up from
> oblivion, but the others just as important.  If a bad request or a
> state transition isn't understood, there is a proper response to it.
>
> -Noah
>
> On Mon, Dec 21, 2009 at 12:48 AM, Jan Algermissen <algermissen1971@...
> > wrote:
>
> On Dec 21, 2009, at 8:54 AM, Eric J. Bowman wrote:
>
> > Jan Algermissen wrote:
> >>
> >> So then, you'd say that it is perfectly RESTful that AtomPub
> >> effectively says "a GET on a collection MUST at least return
> >> application/atom+xml"?
> >>
> >
> > Yes.  That allows for a resource to have more than just an Atom
> > representation.  Reading between the lines and remembering that a
> > request is made up of more than just its URI and method, it also
> > effectively says that a GET request with an Accept header consisting
> > only of 'application/atom+xml' MUST return 'application/atom+xml' or
> > issue a 406 error.
>
> But this means that it is ok for the server to break it's own promise:
> AtomPub says a feed will be available. And it is still ok for the
> server to send me a 406?
>
> Suppose you invested serious money in building that client and the
> spec says that there will be a feed. Suddenly the whole communication
> falls apart, business level harm is done etc. because the service
> sends 406 instead of a feed document.
>
> Whose fault is it and who is going to pay for the damage done?
>
> Jan
>
>
>
>
> >
> > -Eric
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>
> --------------------------------------
> Jan Algermissen
>
> Mail: algermissen@...
> Blog: http://algermissen.blogspot.com/
> Home: http://www.jalgermissen.com
> --------------------------------------
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

--------------------------------------
Jan Algermissen

Mail: algermissen@...
Blog: http://algermissen.blogspot.com/
Home: http://www.jalgermissen.com
--------------------------------------

On Dec 21, 2009, at 6:23 PM, Noah Campbell wrote:

> "But this means that it is ok for the server to break it's own
> promise:
> AtomPub says a feed will be available. And it is still ok for the
> server to send me a 406?"
>
> I'm not sure how this is breaking it's promise?

The spec says that a GET on a collection will return an Atom feed[1].
Yes, I know that the client should prepare for other return codes as
well. But then you can also ask why the spec says what is being
returned at all.

The reason the spec says that an Atom feed is returned is that this
design time information is needed to code an AtomPub client.The
staement cannot be removed from the spec. It is part of the semantics
of application/atomsrv+xml.

AtomPub servers that do not respond with an Atom feed to a GET request
to a collection are breaking clients. And the hint about the other
HTTP codes is just informing the developer to handle it gracefully.
The intended/expected coordination between client and server fails,
regardless of handling the 406 or running into an unhandled exception.
The client cannot do what it was coded to do (coded to do based on [1]).


[1] http://tools.ietf.org/html/rfc5023#section-5.2


>  Don't forget that the response codes are part of the standard
> interface and contract with the client.  While not specific to REST
> (i.e. HTTP is one implementation) the concept of uniform interface
> is.  I think that many people focus on the verbs (GET, PUT, POST,
> DELETE) while very little attention is given to the plethora of
> response codes.  Atompub definitely brought 201 Created up from
> oblivion, but the others just as important.  If a bad request or a
> state transition isn't understood, there is a proper response to it.

Yes. But the proper response isn't helping because the implied
contract is broken anyhow.

Do you think that an AtomPub server that is only capable of replying
to a GET on a collection with an image of the collection is a correct
implementation of RFC 5023?

Should a test tool report an error for such a service because [1] is
not correctly implemented?



Jan



>
> -Noah
>
> On Mon, Dec 21, 2009 at 12:48 AM, Jan Algermissen <algermissen1971@...
> > wrote:
>
> On Dec 21, 2009, at 8:54 AM, Eric J. Bowman wrote:
>
> > Jan Algermissen wrote:
> >>
> >> So then, you'd say that it is perfectly RESTful that AtomPub
> >> effectively says "a GET on a collection MUST at least return
> >> application/atom+xml"?
> >>
> >
> > Yes.  That allows for a resource to have more than just an Atom
> > representation.  Reading between the lines and remembering that a
> > request is made up of more than just its URI and method, it also
> > effectively says that a GET request with an Accept header consisting
> > only of 'application/atom+xml' MUST return 'application/atom+xml' or
> > issue a 406 error.
>
> But this means that it is ok for the server to break it's own promise:
> AtomPub says a feed will be available. And it is still ok for the
> server to send me a 406?
>
> Suppose you invested serious money in building that client and the
> spec says that there will be a feed. Suddenly the whole communication
> falls apart, business level harm is done etc. because the service
> sends 406 instead of a feed document.
>
> Whose fault is it and who is going to pay for the damage done?
>
> Jan
>
>
>
>
> >
> > -Eric
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>
> --------------------------------------
> Jan Algermissen
>
> Mail: algermissen@...
> Blog: http://algermissen.blogspot.com/
> Home: http://www.jalgermissen.com
> --------------------------------------
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

--------------------------------------
Jan Algermissen

Mail: algermissen@...
Blog: http://algermissen.blogspot.com/
Home: http://www.jalgermissen.com
--------------------------------------