search

telefonicaid / fiware-orion

Context Broker and CEF building block for context data management, providing NGSI interfaces.
https://github.com/telefonicaid/fiware-orion/blob/master/doc/manuals/orion-api.md
GNU Affero General Public License v3.0
210 stars 265 forks source link

Fiware-service / servicepath echo #2173

Open jmcanterafonseca opened 8 years ago

jmcanterafonseca commented 8 years ago

I think it could be interesting that there is echo in the CB response when using fiware-service / service-path headers. i.e. include them as part of the response.

Actually it could be an echo or a refinement. For instance, when a wildcard service path is used and the final response only includes data from an specific subservice or set of subservices. So, the response could make concrete what are the subservices that actually provided the data.

kzangeli commented 8 years ago

Not a bad idea. I believe we've discussed this in the past. Don't know why it never got implemented.

fgalan commented 8 years ago

Not sure if this is really part of NGSIv2 or a general functionality. Removing APIv2 label.

jmcanterafonseca commented 8 years ago

general functionality but something worth considering

2016-06-22 15:20 GMT+02:00 Fermín Galán Márquez notifications@github.com:

Not sure if this is really part of NGSIv2 or a general functionality. Removing APIv2 label.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/telefonicaid/fiware-orion/issues/2173#issuecomment-227740820, or mute the thread https://github.com/notifications/unsubscribe/AAqZ_vyX9mQxY9_m3voN4VxCZNQqZ-Ndks5qOTaHgaJpZM4IkhAm .

AnotherCodeArtist commented 8 years ago

You definitely need to include the servicepath of an entity into the response! Is there actually any way to figure out an entity's servicepath other then going for the collection? The problem is that IDAS will create a new entity with the same id/type if the IDAS Service/Sensor does not use the entity's exact service path. This is totally error-prone!

fgalan commented 8 years ago

@AnotherCodeArtist thanks for the comment. Condidering the current NGSIv2 specification (http://fiware.github.io/specifications/ngsiv2/latest/) which mechanism do you suggest, please?

(I have my own ideas but for us first hand feedback from our users is very valuable:)

AnotherCodeArtist commented 8 years ago

Hi @fgalan! The first thing that needs to be changed imho is to add the servicepath attribute that is used as part of the objects "primary key" to every response. What happened in my case was that there had suddenly been two entities with the same name and the same id. So the query: http://orion/v2/entities/[The ID]?type=[The Type] failed, since it returned more than one result. I guess the overall problem is that in the better part of the specification you pretend that every Entity is uniquely identified by a pair consisting of id and type (At least this was what I got out of it). Behind the scenes however, the identifier is a tripple consisting of id,type and servicepath. This is just fine, but you have to provide a way to get this information (e.g. by adding the entity's servicepath attribute to the response). I came across this problem when I was using IDAS. It turned out that a wildcard servicepath ("/*") did not actually work and always produced an error when I tried to add a sensor value. So I had to use the root path initially ("/"). In my sensor registration I referred to a specific Restaurant (id + type), but every time I did so, a new entity with the same id and type and the sensors attribute ("temperature") was created. So I thought the whole thing is extremely buggy. However, when digging into the mongo collection, I figured out that this restaurant had a servicepath set to "/Franchise4". After changing the ServicePath for all IDAS entries (service AND sensor) to this value, everything worked fine. But there is no generic/programmatic way yet to do this, since there was no way to even figure out that this entity has a service path at all.

Another nice option that would hopefully prevent people from running into similar issues were to introduce a new (query-)parameter, that will force an error rather than creating a new entity, if the entity that an operation references to does not exist (and therefore maybe using a switch wether the servicepath should be considered or not in this check). This would have saved me some time ;-).

kzangeli commented 8 years ago

Just one doubt ... The logical place for this 'service path echo' is as an HTTP header, that is pretty clear. But, what if the response contains 52 entities? A comma-separated list of service paths in the HTTP header? (coinciding with the order of the entities in the response), or as a new 'attribute' for the entity?

jmcanterafonseca commented 8 years ago

I would say a comma separated list in the header

2016-09-20 16:38 GMT+02:00 Ken Zangelin notifications@github.com:

Just one doubt ... The logical place for this 'service path echo' is as an HTTP header, that is pretty clear. But, what if the response contains 52 entities? A comma-separated list of service paths in the HTTP header? (coinciding with the order of the entities in the response), or as a new 'attribute' for the entity?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/telefonicaid/fiware-orion/issues/2173#issuecomment-248321083, or mute the thread https://github.com/notifications/unsubscribe-auth/AAqZ_k0DiI_0pAKg1NiTjy1vEO8ppcI9ks5qr_ABgaJpZM4IkhAm .