You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Keith Wall (JIRA)" <ji...@apache.org> on 2015/03/18 13:51:39 UTC

[jira] [Comment Edited] (QPID-6438) [Java Broker] Extend REST interfaces to result in errors when object already exist on create and when object does not exist on update

    [ https://issues.apache.org/jira/browse/QPID-6438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14367084#comment-14367084 ] 

Keith Wall edited comment on QPID-6438 at 3/18/15 12:51 PM:
------------------------------------------------------------

RestServlet.java:

First a couple of superficial comments:

# Line 589, NPE will result if the existing object does not have a name.  I know name is a mandatory attribute but we have taken steps to guard against  null id (which is also mandatory), so it seems odd not to treat name in the same manner.
# RestServlet#createOrUpdate looks confused.   It does an update if parentRequest is false and a create otherwise.  There has to be a clearer way to express this logic.  The otherParents argument is always null.
# RestServlet#equalParents it strikes me odd that a method called equalParents should return true if the otherParents is null or empty.  Why do we consider this to be equal?

Looking deeper it seems like that our approach to create/update has become very complicated and hard to understand.  I think this needs to be refactored.




was (Author: k-wall):
RestServlet.java:

# Line 589, NPE will result if the existing object does not have a name.  I know name is a mandatory attribute but we have taken steps to guard against  null id (which is also mandatory), so it seems odd not to treat name in the same manner.
# RestServlet#createOrUpdate looks confused.   It does an update if parentRequest is false and a create otherwise.  There has to be a clearer way to express this logic.  The otherParents argument is always null.
# RestServlet#equalParents it strikes me odd that a method called equalParents should return true if the otherParents is null or empty.  Why do we consider this to be equal?


> [Java Broker] Extend REST interfaces to result in errors when object already exist on create and when object does not exist on update
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: QPID-6438
>                 URL: https://issues.apache.org/jira/browse/QPID-6438
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Java Broker
>            Reporter: Alex Rudyy
>            Assignee: Alex Rudyy
>             Fix For: 6.0 [Java]
>
>
> At the moment PUT method requests are used for both configured object creation and their updates. Our REST layer looks for ID or name( coupled with object parent) in order to decide whether it is an update request or not. Update is made when object with the same id or the same name and parent is found. Otherwise a new object is created.
> We need to extend existing REST API to return errors in the following cases
> * when object with the same name/id already exists on create 
> * when  object does not  exists on update
> The existing REST interfaces should not be affected by the change and should continue working as expected keeping backward compatibility.
> The REST interfaces will be changed as depicted below
> h2. CO creation
> Methods PUT or POST can be used to create CO.
> CO can be created by submitting PUT request to CO URI with body containing object json or by submitting PUT/POST request to parent URI.
> The request encoding should be json (application/json) and request body should contain a CO json object.
> On successful completion of operation a response code 201 should be returned  and response header "Location" should be set to CO URI. 
> If object with a such name/id already exist and parent URI is used to create object, an error response with response code 409 (conflict) and body containing json with the reason of operation failure should be returned. On any other error, response with response code 400 (bad request) or  422 (validation error) and body containing json with the reason of operation failure should be returned.
> If object with a such name/id already exist and object URI is used, then CO update should be performed.
> For example, if Queue with name "my-queue" needs to be created on a virtual host with name "vh" (which is contained within virtual host node with name "vhn") either of the following requests should be made
> {noformat}
> PUT /api/latest/queue/vhn/vh HTTP/1.1
> {noformat}
> {noformat}
> POST /api/latest/queue/vhn/vh HTTP/1.1
> {noformat}
> {noformat}
> PUT /api/latest/queue/vhn/vh/my-queue HTTP/1.1
> {noformat}
> Response code 201 should be returned on successful queue creation. Response header "Location" should be set to "/api/latest/queue/test/my-queue".  If queue with a such name already exist with either of 2 first requests above, an error response with response code 409 (conflict) and body containing json message that queue exists should be returned. If queue with a such name already and last request is used, then CO update should occur.
> h2. CO update
> Methods PUT or POST can be used to update CO. Update request should be made against CO URI.
> If CO does not exists and PUT method is used, such object should be created
> If CO does not exists and POST method is used, an error should occur and response with error code 404 and json with error message should be returned.
> The request encoding should be json (application/json) and request body should contain a CO json object (with all or changed only attributes)
> On successful completion of operation a response code 200 should be returned. If any error occur on update, a response with response code 400 or 422 or 404 should be sent back to the client containing json body with error details.
>  For example, if Queue with name "my-queue" is required to be updated on a virtual host with name "vh" (contained in virtual host node with name "vhn") either of the following requests should be made:
> {noformat}
> POST /api/latest/queue/vhn/vh/my-queue HTTP/1.1
> {noformat}
> {noformat}
> POST /api/latest/queue/vhn/vh/my-queue HTTP/1.1
> {noformat}
> We need to change REST documentation to cover the changes



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org