Amine Aouled Hamed amine.ahd at gmail.com
Mon Dec 11 04:49:04 EST 2017

I agree that JSON is too basic and simple it doesn't need much talk, so
maybe lets leave it until the end and if someone needs any explanation we
can still talk about it.
For the REST API I don't have a concrete presentation but rather some
points to talk about. I will be happy to outline what needs to be discussed
with you, feel free to contact me so we can talk more about it.
Good point about HTTP and CoAP, I will try to add some points about them in
the overview page and maybe discuss them in our next meeting.


On Wed, Dec 6, 2017 at 12:25 PM, Gunnar Andersson <gandersson at genivi.org>

> Hello Amine,
> I added [GPRO] label to the subject to indicate it is within the Generic
> Communication Protocols Evaluation project.
> On Wed, 2017-12-06 at 10:48 +0100, Amine Aouled Hamed wrote:
> > Hi all,
> > Unfortunately due to an unexpected issue I was not able to join the comm
> > protocols meeting of yesterday in which I wanted to talk about JSON and
> > RESTful API
> No problem.  See you next time.
> > therefore I will right my thoughts here to be discussed.
> > Having personally worked with both I think they are the best candidates
> > compared to similar technologies for what they offer:
> >
> > JSON:
> > I found JSON much better in term of readability compared to XML which
> > arguably makes it easier to debug and also easier to process as it
> > naturally maps to most programming languages used in Embedded systems
> > (notably C/C++). There exist also many mature and efficient libraries to
> > handle JSON and at the same time validate it (there do exist a JSON
> scheme
> > standard as well).  Having this standard helps a lot in ensuring the
> > integrity and the validity of the data being communicated.
> > JSON is used in many places and getting more visibility compared to XML
> in
> > all areas especially the web and so it makes sense if we would like to
> > communicate with the external world.
> All of that makes sense.  One of the comments we made yesterday was that
> JSON is almost too basic to talk about among the participants in this group
> - but since we said we would do something very short, like 5 minutes
> overview, on every topic, I see no problem to do that also for JSON.
> After all, one of the defined early goals, as a foundation to reach the
> more
> ambitious goals is to ensure the same level of knowledge across the project
> participants.  And if the first meetings concentrate on the more well known
> technologies, later meetings will still cover the less known alternatives.
> > RESTful API:
> > RESTful API is not a protocol but rather a style or a set of practices on
> > how communication between different applications should be. This makes it
> > flexible by nature as the choice of protocols and technologies to use is
> > up to the developer to decide. Most common infrastructure used in RESTful
> > API is HTTP/HTTPs because of how naturally the methods map to the idea of
> > REST(GET, POST, DELETE etc...).
> > Same as JSON, RESTful is being used more and more compared to SOAP for
> > example and today almost any decent cloud service is offering a REST API
> > therefore it makes sense to use it as a way of communicating with 3rd
> > party services as well as private services.
> Indeed, REST is a very widely used principle in today's computing, and many
> will be familiar with it, but maybe not everyone know ALL the details. It
> is
> such a popular and important principle that it is worthwhile describing and
> communicating this in a little bit of depth anyway.  I was considering to
> take it, but will happily get the presentation from you.  If you want, we
> could outline the points to cover together?   I'd recommend something more
> like 10 minutes to introduce it in sufficient detail?
> When we schedule that topic we should essentially cover HTTP of course, and
> I was considering therefore to also cover CoAP in the same session, since
> it
> aligns very well.   And MsgPack and JSON are also siblings.  Let's just
> schedule these into agendas and make sure it all fits.
> >
> > Finally, those two technologies are almost always used together which
> > means there exist a lot of resources out there and can be used right
> > always which reduces the time and effort needed to get something up and
> > running.
> >
> > I will try to continue filling up the overview page any help would be
> > appreciated as I am not familiar with some of them.
> >
> > Regards,
> > Amine.
> > _______________________________________________
> > genivi-projects mailing list
> > genivi-projects at lists.genivi.org
> > https://lists.genivi.org/mailman/listinfo/genivi-projects
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genivi.org/pipermail/genivi-projects_lists.genivi.org/attachments/20171211/f57521b8/attachment.html>

More information about the genivi-projects mailing list