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 <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
>
>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
