Re: [Architecture] [APIM][C5] - Definining Endpoint for Resource from Rest API
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 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 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 : >> >>> Hi All >>> >>> On Tue, Dec 20, 2016 at 9:48 PM, Frank Leymann 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 : > Yes i also think same way. I believe we should add sub resources only > if it has its own life cycles and i
Re: [Architecture] [APIM][C5] - Definining Endpoint for Resource from Rest API
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 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 : > >> Hi All >> >> On Tue, Dec 20, 2016 at 9:48 PM, Frank Leymann 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 : >>> 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 wrote: > Hi Tharindu > > Instead of exposing new API resources can we use API Definition to > capture those details for
Re: [Architecture] [APIM][C5] - Definining Endpoint for Resource from Rest API
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 : > Hi All > > On Tue, Dec 20, 2016 at 9:48 PM, Frank Leymann 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 : >> >>> 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 >>> 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
Re: [Architecture] [APIM][C5] - Definining Endpoint for Resource from Rest API
Hi All
On Tue, Dec 20, 2016 at 9:48 PM, Frank Leymann 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 :
>
>> 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 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/{A
Re: [Architecture] [APIM][C5] - Definining Endpoint for Resource from Rest API
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.
Line 211 says that an attribute status is returned (in case of status code
200): where is it returned? The body must be empty!
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.
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.
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.
Best regards,
Frank
2016-12-20 7:08 GMT+01:00 Sanjeewa Malalgoda :
> 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 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
>>
>> * *
>>
>>
>
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779 <+94%2071%20306%208779>
>
>
Re: [Architecture] [APIM][C5] - Definining Endpoint for Resource from Rest API
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 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
>
> * *
>
>
--
*Sanjeewa Malalgoda*
WSO2 Inc.
Mobile : +94713068779
Re: [Architecture] [APIM][C5] - Definining Endpoint for Resource from Rest API
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
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/
> 0d61ece09a4fc1cc24aa4616f63245a57decfe14/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
* *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] [APIM][C5] - Definining Endpoint for Resource from Rest API
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/0d61ece09a4fc1cc24aa4616f63245a57decfe14/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*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
