Hi All On Tue, Dec 20, 2016 at 9:48 PM, Frank Leymann <[email protected]> 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 <[email protected]>: > >> 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 <[email protected]> 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 < >>> [email protected]> 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 >> [email protected] >> 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 [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
