Hi Jo, yes, 400 is correctly used to indicate validation errors of message bodies of POST requests.
I didn't know about Swaggers Security Scheme Object: great that we are planning to use it :-) Best regards, Frank 2016-12-21 3:53 GMT+01:00 Joseph Fonseka <jos...@wso2.com>: > Hi All > > On Tue, Dec 20, 2016 at 9:48 PM, Frank Leymann <fr...@wso2.com> wrote: > >> If an API Resource or endpoint is nothing stand-alone, i.e. if it needs >> an API Definition and can't live without it, it should be nested under API >> Definition. Thus, "+1! >> >> Furthermore, I took a look at [1]. In line 167, a HEAD method is >> defined. A HEAD on a certain URI returns the very same than a GET except >> that a HEAD must not (!) return a body. A HEAD is used to check the HTTP >> header fields of a given resource without returning the resource itself; >> also, a HEAD is used to get aware of Authentication requirements in case of >> PUT/POST before sending large bodies and getting a 401 back. Thus, it is >> somehow "a stretch" to use HEAD to check conditions like proposed in the >> API definition. >> > > +1 Also I think we can go without the HEAD method. We can use the same > APIs listing resource "/apis GET" to search on a given context which is > already implemented. Benefits would be one less resource to implement and > maintain. > > > >> Line 220 says that in case of status code 400 the API attribute specified >> in the query string of the request does not meet the requirements. This is >> not what status code 400 is used for: 400 is returned in case the request >> was malformed, had syntax errors etc. Thus, the use of 400 as proposed is >> not standard compliant and should not be realized as is. >> > > @Frank to clarify, It make sense not to issue 400 if the query parameters > are malformed but can we use 400 if there are validation errors with the > data submitted with a POST request. > > >> >> Line 224 says that a certain attribute does not exist in case of a 404 >> status code. Well, status 404 is returned if the whole resource cannot be >> found. In this case (i.e. client specified a non-existent attibute) the 400 >> status code is appropriate. >> > > +1 In this case if an API with the given context do not exist we can > return 200 with a empty list ( assuming we are using /apis GET resource ). > > >> Also, I see a couple of user defined headers (x-wso2...). User defined >> attributes are not RESTful, but in well-argued cases they are fine. For >> example, x-scope is user defined (not a w-wso2-... header?), and it seems >> to be security related; isn't that somehow covered by bearer authentication >> that allows to pass a scope parameter? As you know, I am not really a >> security expert, thus, you have to educate me :-) I don't understand the >> use of x-wso2-curl, x-wso2-request, and x-wso2-response. >> > > @Frank We use those attributes ( ie x-wso2-curl ) to generate API > documentation and they will not effect API run-time. see [1]. How ever we > have planed to use swagger security object [2] instead of x-scope ( which > is there for historical reasons ). > > Thanks & Reagrds > Jo > > > [1] https://docs.wso2.com/display/AM200/apidocs/publisher/ > [2] http://swagger.io/specification/#securityRequirementObject > > > > >> >> >> Best regards, >> Frank >> >> 2016-12-20 7:08 GMT+01:00 Sanjeewa Malalgoda <sanje...@wso2.com>: >> >>> Yes i also think same way. I believe we should add sub resources only if >>> it has its own life cycles and its own usage even without dependency to >>> root resource. >>> But for me endpoints are tightly bound to API unlike other sub >>> resources. If we consider image like resource then even without API >>> dependency it has its own mean. Same applies for swagger definition etc. >>> But IMO sub resources and its attributes are bit different from them and >>> more like API meta data. WDYT? >>> >>> Thanks, >>> sanjeewa. >>> >>> On Tue, Dec 20, 2016 at 11:25 AM, Joseph Fonseka <jos...@wso2.com> >>> wrote: >>> >>>> Hi Tharindu >>>> >>>> Instead of exposing new API resources can we use API Definition to >>>> capture those details for example scopes and authentication types are >>>> already captured in the API Definition ( Swagger ) with vendor extension >>>> attributes. >>>> >>>> In the above case If a client want to update any of the resource values >>>> they can simply submit the updated API Definition. >>>> >>>> Thanks >>>> Jo >>>> >>>> On Tue, Dec 20, 2016 at 10:39 AM, Tharindu Dharmarathna < >>>> tharin...@wso2.com> wrote: >>>> >>>>> Hi All, >>>>> >>>>> We are going to implement REST API to do the following functionality >>>>> on C5. >>>>> >>>>> *Functionality* >>>>> >>>>> 1. Add API Resource >>>>> >>>>> 1. Endpoint configuration >>>>> 2. Resource level policy >>>>> 3. Authentication Type for resource (Any,Application user ,etc.) >>>>> 4. Scope >>>>> >>>>> 2. Update API Resource >>>>> 3. Delete API Resource >>>>> 4. GET API Resource. >>>>> >>>>> We had concern of following approaches to handle the above resource. >>>>> >>>>> 1. Handle as element in the API as [1]. >>>>> >>>>> 2. Make SubResource of the API. >>>>> >>>>> - /apis/{API_ID}/resources - Post (Add resource) >>>>> - /apis/{API_ID}/resources/{resourceid} - GET (Get Specific >>>>> Resource) >>>>> - /apis/{API_ID}/resources/{resourceid} - PUT (Update Specific >>>>> Resource) >>>>> - /apis/{API_ID}/resources/{resourceid} - Delete (Delete Specific >>>>> Resource) >>>>> - /apis/{API_ID}/resources - GET (Get All Resource according to >>>>> the API) >>>>> >>>>> >>>>> In order to handle above resources we are going to give resource in >>>>> the API model of rest API as [1]. >>>>> >>>>> [1] - https://github.com/tharindu1st/carbon-apimgt/blob/0d61ece0 >>>>> 9a4fc1cc24aa4616f63245a57decfe14/components/apimgt/org.wso2. >>>>> carbon.apimgt.rest.api.publisher/src/main/resources/publisher-api.yaml >>>>> >>>>> Please add your suggestions into the above approaches. >>>>> >>>>> Thanks >>>>> >>>>> *Tharindu Dharmarathna*Software Engineer >>>>> WSO2 Inc.; http://wso2.com >>>>> lean.enterprise.middleware >>>>> >>>>> mobile: *+94779109091 <+94%2077%20910%209091>* >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> -- >>>> *Joseph Fonseka* >>>> WSO2 Inc.; http://wso2.com >>>> lean.enterprise.middleware >>>> >>>> mobile: +94 772 512 430 >>>> skype: jpfonseka >>>> >>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>> >>>> >>> >>> >>> -- >>> >>> *Sanjeewa Malalgoda* >>> WSO2 Inc. >>> Mobile : +94713068779 <+94%2071%20306%208779> >>> >>> <http://sanjeewamalalgoda.blogspot.com/>blog >>> :http://sanjeewamalalgoda.blogspot.com/ >>> <http://sanjeewamalalgoda.blogspot.com/> >>> >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> > > > -- > > -- > *Joseph Fonseka* > WSO2 Inc.; http://wso2.com > lean.enterprise.middleware > > mobile: +94 772 512 430 > skype: jpfonseka > > * <http://lk.linkedin.com/in/rumeshbandara>* > >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
