Hi, I don't quite agree that an Endpoint is a dependent Resource. IMO an endpoint is a standalone resource which has its own meaning. It may have attributes such as name, URI, timeouts, suspension codes, etc. Therefore I think an endpoint is a unified resource which can be used by various sources such as API Proxies, Applications, Message Processors, etc.
A given API-Proxy/API-Resource, may or may not depend on an Endpoint. And a given Endpoint may be used by one or more API-Proxies/API-Resources. Therefore I think we should model this in such a way that we consider an Endpoint as a standalone entity. If an API-Proxy or API-Resource depends on an Endpoint, it should have a reference (link) to the particular Endpoint in interest. Thanks, NuwanD. On Thu, Dec 22, 2016 at 11:00 PM, Frank Leymann <[email protected]> wrote: > 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 <[email protected]>: > >> 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/publishe >>>>>> r-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 > > -- Nuwan Dias Software Architect - WSO2, Inc. http://wso2.com email : [email protected] Phone : +94 777 775 729
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
