Arthur,

While I am not advocating that we respond with a 4xx when the server does
not update a resource at a client's request.  I point it out as an example
of how even RFC2616 requires some interpretation in context.

What I do want to do is address this very real problem (that DM and RRC are
experiencing) that clients have when attempting to update resources (in
general).

Using your own Java analogy, a program that essentially is

x = -42;
out.println( x );

where the output is +42, because this particular type of variable only
understands positive integers, and the programmer doesn't know this.  Now
he is forced to check every time he makes an assignment before proceeding
with the program

x = -42;
if( x != -42 ) throw exception

I think because the OSLC explicitly says that the server can ignore
unrecognized content, and there is no guaranteed way for a client to know
what content the server recognizes, the onus is on the client to be
responsible for checking the results.  I think we should provide some
guidance and raise awareness of this scenario in our specs
(non-normatively), so client developers can be prepared for this situation.

I am ok if we just state that this scenario can happen, and that the client
is responsible for determining if the update was successful (from its view)
by GETing the representation immediately after and checking the content and
comparing the ETags.


Thanks,

jim conallen
Rational Design Management (DM) Integration Architect, OSLC AM Lead
[email protected]
Rational Software, IBM Software Group





From:   Arthur Ryman/Toronto/IBM@IBMCA
To:     James Conallen/Philadelphia/IBM@IBMUS,
Cc:     Adam Neal <[email protected]>, [email protected],
            [email protected]
Date:   09/13/2012 04:03 PM
Subject:        Re: [oslc-core] Unrecognized content


Jim,

I disagree. The server ignored the content it didn't understand and did the
update, but the before and after state was the same. According to your
proposal, if I did a GET and then immediately PUT the resource, that should
also result in an error because nothing changed. That would not be
reasonable.

Consider the following Java program:

int x = 42;
x = 42;

That shouldn't result in a compiler error.

In fact, the behavior of the server is somewhat undefined if a PUT would
result in no change to the resource. The server could try to be clever and
only update the resource if some property changed. Or it could take the
request literally and replace the resource with an identical copy, but as a
side affect, the modification date of the resource might change.


Regards,
___________________________________________________________________________

 Arthur Ryman

 DE, Chief Architect, Reporting &

 Portfolio Strategy and Management

 IBM Software, Rational

 Toronto Lab | +1-905-413-3077 (office) |
 +1-416-939-5063 (mobile)






|------------>
| From:      |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------|
  |James Conallen/Philadelphia/IBM@IBMUS                                        
                                                               |
  
>--------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman <[email protected]>                                              
                                                               |
  
>--------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------|
  |Adam Neal <[email protected]>, [email protected], 
[email protected]                                          |
  
>--------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------|
  |09/07/2012 11:16 AM                                                          
                                                               |
  
>--------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] Unrecognized content                                         
                                                               |
  
>--------------------------------------------------------------------------------------------------------------------------------------------|




Hey Arthur,

The spec for the PUT method says:

If an existing resource is modified, either the 200 (OK) or 204 (No
Content) response codes SHOULD be sent to indicate successful completion of
the request. If the resource could not be created or modified with the
Request-URI, an appropriate error response SHOULD be given that reflects
the nature of the problem.

In this scenario the server did not modify the resource, because it didn't
recognize the content.  So according to RFC 2616 we should be returning an
error response.


Thanks,

jim conallen
Rational Design Management (DM) Integration Architect, OSLC AM Lead
[email protected]
Rational Software, IBM Software Group






From:   Arthur Ryman <[email protected]>
To:     James Conallen/Philadelphia/IBM@IBMUS,
Cc:     Adam Neal <[email protected]>, [email protected],
            [email protected]
Date:   09/07/2012 10:15 AM
Subject:        Re: [oslc-core] Unrecognized content



-1 for the 400 response code

Jim, I don't understand what you are asking for. The spec already makes it
clear that the server will discard unrecognized content. The client should
expect that. What aspect of behavior is unclear?

Regards,
___________________________________________________________________________


Arthur Ryman

DE, Chief Architect, Reporting &
Portfolio Strategy and Management
IBM Software, Rational

Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
James Conallen <[email protected]>
To:
[email protected]
Cc:
Adam Neal/Ottawa/IBM@IBMCA
Date:
09/07/2012 09:03 AM
Subject:
[oslc-core] Unrecognized content
Sent by:
[email protected]



In the current specification we have the statement:
For OSLC Defined Resources, clients SHOULD assume that an OSLC Service
will discard unknown property values. An OSLC Service MAY discard property
values that are not part of the resource definition or Resource Shape
known by the server.

We are running into a problem. When a client (in this case another
application server) PUTs an update to a resource that includes a 'link' to
another OSLC resource, and the server, at the time does not recognize the
link type, the link is not accepted, but a 200 OK is returned.  The server
returns a 200 OK, because it feels like it can ignore the unrecognized
link.  The client gets that 200 OK, and thinks that the link was
successfully added.

This doesn't feel right.  The only way a client can be sure that the PUT
worked as expected is to re-GET the resource and compare it to what it
expected to see (with the new link included), and maybe do a little
looking at ETags to make sure things haven't changed in between.

I guess the server could instead return a 400 Bad Request, and include in
the response the reason for not accepting the PUT.  But if the content
that was submitted really should just be ignored (i.e. is part of a future
version of the resource), then we don't want to abort the update.

The OSLC verbage does not provide any guidance as to what to do.  It would
be helpful if we had more detailed explanation of this statement in the
spec.


Thanks,

jim conallen
Rational Design Management (DM) Integration Architect, OSLC AM Lead
[email protected]
Rational Software, IBM Software Group
_______________________________________________
Oslc-Core mailing list
[email protected]
http://open-services.net/mailman/listinfo/oslc-core_open-services.net




Reply via email to