Yes i don't see issue in making endpoint is independent resource. If we consider sub resources then they are directly bound with APIs. So i think having sub resources and their attributes as part of API model with endpoint mapping there is fine. In my previous reply i wanted to emphasize that sub resources(sub paths +HTTP verbs) cannot decouple from API model. But mistakenly endpoint word is there and hence made confusion.
Thanks, sanjeewa. On Mon, Jan 2, 2017 at 12:51 PM, Nuwan Dias <[email protected]> wrote: > 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 <077%20777%205729> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Sanjeewa Malalgoda* WSO2 Inc. Mobile : +94713068779 <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
