When a client renders a URLs it need to know everything about them. This includes data from Magnet Content Service and metadata from the web.
Improves magnet-client
Right now the magnet-client has to make two separate requests and merge the results to create the data-model needed to render an item view. This risks leading to inconsistencies.
Improves magnet-metadata-service
magnet-metadata-service has recently introduced a dependency on content-service to resolve extra_metadata and call_to_action. If we had this new endpoint we could remove this coupling and leave magnet-metadata-service to focus on only on extracting metadata from web pages.
Ideally we want to POST a list of urls and receive back a list (of matching length and order) something like:
{
// url that uniquely identifies this item within magnet-service
"id": ...,
"lat": ...,
"lon": ...,
// merge of web metadata and magnet-content-service metadata
"metadata": {
...
}
}
When a client renders a URLs it need to know everything about them. This includes data from Magnet Content Service and metadata from the web.
Improves magnet-client
Right now the
magnet-client
has to make two separate requests and merge the results to create the data-model needed to render an item view. This risks leading to inconsistencies.Improves magnet-metadata-service
magnet-metadata-service
has recently introduced a dependency oncontent-service
to resolveextra_metadata
andcall_to_action
. If we had this new endpoint we could remove this coupling and leavemagnet-metadata-service
to focus on only on extracting metadata from web pages.Ideally we want to POST a list of urls and receive back a list (of matching length and order) something like: