[Fiware-ngsi] Standard operations support

[marc.capdevielle at orange.com]

Hello,

To simplify the ongoing discussions, I propose we take each discussion 
point from the "[Fiware-ngsi] FIWARE NGSI API discussion points"  as a 
separate threads.

------


[TJ] I think it would be good to keep the approach of having a set of 
basic operations (queryContextRequest etc.) with which in principle one 
can do everything, so that convenience operations only add convenience 
but not add functionality as compared to the basic operations?

[FGM2] In general, I agree. In fact, we plan to include standards 
operations also as part of the reference documentation. As I mention in 
my previous email: /"The current draft at the above URL is focused on 
not-standard operations (sometime referred as "convenience operations") 
but at the end it will also include a specification for the standard 
operations (e.g. queryContext, updateContext, registerContext, etc.) 
based in the one we already have for the JSON encoding of that 
operations in the v1 API"./ However, there are some exceptions, eg: the 
convenience operation to get all the entity types ("GET /v2/types") in 
the sytesm doesn't have any counterpart in the standards operation 
family. But I understand that this is not a mayor problem.


[JH]  We definitively should keep the non-convenience operations (I 
wouldn't call them "standards" by the way, maybe we need to call them in 
another way).   However, I understand that we will implement some of the 
simplifications in the returned JSON structures, aren't we?   Leaving 
the developer the option to choose between self-contained (verbose :-) 
JSON structures and more simplified structures also would apply for 
these kind of operations.

[MC] As newcomers to the NGSI / Fiware ecosystem, me and some colleagues 
of mine have found very confusing that NGSI v1 exposes multiple ways of 
accessing the exact same information thought the standard and 
convenience operations. After a quite heated discussion with Tobias at 
the F2F meeting in Heidelberg, I now have a better understanding of the 
historic reasons that pushed the decision to have a subset of the NGSI 
standard operations duplicated as "convenience" REST endpoints... but I 
still think it was an error in the first place. Accepting that some 
developers need a more "convenient" way to access data is accepting that 
standard operation are not convenient (by not being RESTfull) and that 
design of the NGSI v1 APIs is flawed in some way.

The first thing to decide (and there was no consensus at the F2F 
meeting) is whether NGSI v2 is about :
- breaking compatibility with v1 allowing to change all the APIs,
- keeping compatibility with v1 and just adding missing functionalities 
(more a v1.1),
We need to decide on that first.

Then, *if* the NGSI v2 specification is about breaking compatibility 
with v1 and simplifying it using REST endpoints, it *may* be the right 
time to discuss if the standard operations need to be included in v2 and 
if we can move all the NGSI functionalities to "REST-like" endpoints. I 
say only "REST-like" as some NGSI concepts cannot be mapped fully to 
REST properly.

On another side, I don't have anything against keeping the standard 
operations for v2. But then, we should accept that the NGSI model is not 
adapted to the REST conventions and don't try to apply REST partially by 
duplicating endpoints.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20150710/8c2db010/attachment.html>