Assume you have an eCommerce site from which you sell some product. You also sell that product on Amazon. What would be the SEO implications of using the sameAs property in your eCommerce site's ld+json to link to your Amazon URL as well? Is this a valid practice and would you gain anything by it?
For example:
{
"#context":"https://schema.org/",
"#type":"Product",
"sameAs":[AMAZON URL HERE],
"name":"My Product",
"image":"myproductimage.jpg",
"description":"my description",
"brand":{
"#type":"Thing",
"name":"Brand"
},
"sku":"SKU",
"mpn":"MPN",
"offers":{ ... }
}
N.B. I had previously asked this question here: https://opendata.stackexchange.com/questions/16016/ldjson-use-for-sameas-product since I tagged it as linked-data and that tag suggested posting there instead. But, I am not sure if it actually makes more sense to ask here since I've also seen several ld-json questions.
Description of this property from Schema:
URL of a reference Web page that unambiguously indicates the item's
identity.
We discuss activity in the digital domain can, therefore, make sense to check the Digital identity value of Wikipedia:
A digital identity is information on an entity used by computer
systems to represent an external agent. That agent may be a person,
organization, application, or device. ISO/IEC 24760-1 defines identity
as "set of attributes related to an entity".
In my humble opinion, the web page for selling your product on Amazon can hardly be called digital identification.
Information from Wikipedia, from Wikidata, from DBpedia and similar resources are more suitable for product identification.
Related
Link to the HATEOAS This is the link to the Hateoas article (snapshot below) where the identifiers of the resource is part of the URL i.e. 12345. Here the API response has the final API relative URL i.e. /accounts/12345/deposit and the client just needs to hit it.
Link to the Github Users API This is the link to the Github API (snapshot below) where there are lots of placeholders for identifiers. How will clients modify these URLSs and add a value in these placeholders? For example, {/gist_id}, {/other_user}.
Isn't passing the URL with id value instead of placeholder better? Why and when to rely on different clients to add values in these placeholders?
Hypertext as the engine of application state (HATEOAS) is a bit more than just the usage of links. In essence it enforces the interaction model that is used on the Web for two decades quite successfully. On the web a server usually "teaches" clients (browsers) to achieve something via the help of link relations, that can be used to automatically download related resources or give a hint on the reference resource, and Web forms, that define the syntax and semantics of each of the respective supported (input) elements, i.e. a text field, an option element to select one or multiple choices, a drop down or even a slider widget. Based on the affordance of each of the elements a client knows i.e. that a button wants to be clicked or pressed while a text fields wants some user input and stuff or a link annotated with the prefetch link relation name may be downloaded automatically once the current page finished loading as a client might invoke it next or a preload link relation might instruct a user agent to load the referenced resource early in the current page loading process.
The form not only teaches a client about the supported fields a resource has but also about the target URI to send the request to, the HTTP method to use wile sending the request as well as the media-type, which in the case of Web forms is usually implicitly set to application/x-www-form-urlencoded.
In an ideal world a client just uses the information given by the server. Unfortunately, the world isn't perfect and over time people have come up with plenty of other solutions. Among one of them is URI templating that basically allows clients to use a basic URI and fill out certain placeholders with concrete values. As making use of templating requires some knowledge of the URIs intention or the parameters you need to pass, such capabilities make only sense as part of media-type support.
Plain JSON (application/json) has by default no support for URIs whatsoever and as such a user agent receiving a plain JSON payload might not be able to automatically replace a template URI with a concrete one out of the box. JSON Hyper-Schema (application/schema+json) attempts to add link and URI template support to plain JSON payloads. A user client though needs to be hinted with the appropriate media-type in order to automatically resolve the full URI. As such, the user agent also has to support that respective media type otherwise it won't be able to process the document (resolve the template URI to a real URI) successfully.
JSON Hypertext Application Language a.k.a HAL JSON also supports URI templates for links. application/collection+json does support two kinds of templates - query templates and objects-template. The primer one is similar to a URI template by allowing to append certain query parameters to the target URI upon sending the request while the latter one allows to define a whole object that contains all the input elements used to add or edit an item within the collection. JSON-LD does not really support URI templating AFAIK though it uses the concept of a so called context where certain terms can be used to abbreviate URIs. As such something like name can be used within the context for a URI like http://schema.org/name.
As you can hopefully see, the support for URI templating depends on the media-type used for exchanging data. In the case of the outlined github example GET /users/:username this more or less resembles a typical Web API documentation, similar as it is done in a Swagger API documentation, that unfortunately has hardly anything to do with HATEOAS.
For your top example (banking), you should absolutely include the complete URL, with account numbers (IDs), so that the client does not need to translate/substitute anything. This is the most common scenario with HATEOAS. However, GitHub does have those "placeholders" for endpoints that could contain multiple values. You can't include the "following_url" for every user in the response, it's not practical. So you have to determine the "other_user" value another way and make the substitution. Personally, I haven't even had this use case with any of my applications and all of my HATEOAS URLs resemble you first example (though I prefer full URLs not relative). Unless you have specific cases like GitHub does, it's not necessary to use any of these placeholders. Even GitHub only uses that where they could be multiple values. For fixed value URLs, they have the username (like your account number) in the URL ("octocat").
According to me we should not give the direct url in the body
We should always parameterized the api and get details form there.
In simple case if Id of data change than every time data need to update for detail url.
Else if it’s dynamic you will never face this issue.
And this also come under best practices.
If you go to business manager of facebook, then go to the "All Audiences", then under the "Audiences" tab, you will see a "Filters" button right beside the "Create Audience" button. Now my question is, which part the json data being provided by the facebook apis should I based the data that I should pull out based from these filters ?
- Recently Used
- In Active Adverts
- Action Needed
- Shared
Because unlike the "ready" and "not ready" status, those four filters that I mentioned are not straight forward where I can just look for the numbers from the returned json data. so how ?
Most likely, not all of this information is available through the API.
However, if you take a look at the following doc, you can see some reelvant fields that may help:
https://developers.facebook.com/docs/marketing-api/reference/custom-audience
Most likely you can use the field operation_status to look at whether an audience needs action.
For whether it's shared, take a look ad the edge adaccounts which will let you see the ad accounts this audience has been shared with.
For recently used, you'll probably have to look at the edge ads and review the status of the ads.
To save having to make multiple requests, you can take a look at field expansion in the Graph API, which will let you query for fields of objects in results using a single request:
https://developers.facebook.com/docs/graph-api/using-graph-api#fieldexpansion
We have listing and details page for mobile, desktop, android and ios?
We have two apis- one for listing and other for details of those listings. So one api is assosiated with other.
listing api looks like:
/api/books/?price=100-300
details api looks like:
/api/book/{bookId}
listing api in response sends back details api link for each listing:
For example:
Request:
/api/books/?price=100-300
will have Response:
{
"books":[
{
"id": 1,
"price": 120,
"pages": 400,
"detailsUrl": "/api/book/{bookId}"
}
]
}
The problem is, should I send detailsUrl with each listing or let all the clients create this? Since they have bookId, they can create it.
What is considered to be best practise considering the url params in details api url may get added in future, api may be versioned and all other possibilities for widely used apis?
I'd put my money on creating the link.
There is a perfect explanation why putting id is not enough
DO NOT include just an entity's ID (such as 12) in a response, because
that way you're forcing clients to put together resource URIs
themselves. In order to do that, they would need to have prior
knowledge of what URIs there are, and you're losing control over the
URI space on the server side.
I recommend to read the entire, linked text (approved answer), it's very detailed and got nice resources. As the author mentioned, there is a popular convention how to make connections between resources - HAL. Consider this instead of detailsUrl.
Even if a link to the resource is obvious right now and you decided to put id alone, in other resources after some time it won't be so simple and you will be forced to specify full URL. Then your API won't be consistent. Experience has taught me it's always easier and better for maintenance to send back full link.
In golang, is there a way to pipe a variable to part of a web form?
For example, sending "123 Random St." to the Street address part of https://www.dominos.com/en/pages/order/#/locations/search/ and so on? I found pizza_party*, but the GUI used is no longer available, I have also found pizzadash**, but this uses a credit card where I want to use cash. I even found a list of golang ones, but the links that they use doesn't work anymore.***
Therefore, my goal is so: order a pizza in golang through the dominos website API!
NOTE: Please suggest a package or function with example!
NOTE: I do not want to make a web scraper/data getter.
NOTE: Your answer must work on at least one box of my linked website.
NOTE: I want to fill out links similar to the provided link from the linux command line.
*https://github.com/coryarcangel/Pizza-Party-0.1.b
**https://github.com/bhberson/pizzadash
***https://golanglibs.com/top?q=pizza
This is how you post any form values onto an online form. Provided you know the POST endpoint of the service.
func main():
resp, err := http.PostForm(targetPostUrlHere,
url.Values{"Service_Type": {"Delivery"},
"Address_Type_Select": {"House"},
"Street": {"123 E 24th St"},
"Address_Line_2": {"4D"},
"City": {"New York"},
"Region": {"NY"},
"Postal_Code": {"10027"}})
}
**Note: The field keys and values are guesstimates. You must inspect the actual key names expected in the form.
In your case, https://www.dominos.com/en/pages/order/ is an endpoint for the form page. Once the form is filled and submitted, the information is submitted using POST method akin to the code afore-mentioned to a dedicated CREATE endpoint (C in the CRUD), which normally can be found in the <form> html tag.
<form action="posttargetendpoint" method="POST">...</form>
Once the POST operation is successful, usually a web service would redirect you to another page. In your case, it is https://www.dominos.com/en/pages/order/#/section/Food/category/AllEntrees/
However, any good web service wouldn't expose the POST endpoint in the clear since it is the vulnerable point of attack. You're welcome to find out by inspect he Domino's page source and adjust the field values in the Go code accordingly.
Now to make a command line prompt to wrap around the PostForm code, I suggest you look into https://github.com/codegangsta/cli which is a very nice package for creating quick command line app.
I assume you mean pipe information originating from your backend to another site on behalf of a user?
The standard way of passing information between domains is via HTTP params, usually via a GET request, but this capability would need to be supported by established protocols the remote site. You can also use an iframe to embed the page of another site onto your page, however, you wouldn't be able to remotely interact, call JS code, or even query the page at all. Cross-domain security safeguards justifiably prohibit such capability, and generally speaking, interacting on behalf of the user via their browser is also restricted for security reasons.
However, if you're looking to emulate user behavior such as with a bot or web scraper from your own host or browser then that's a different story. There are tons of frameworks provide rich capability for interacting with a page. I'd recommend checking out Selenium, which acts as a virtual browser. There are also tons of libraries in Python for processing data from HTML and structured data. You might want to check out Beatiful Soup and Scrapy.
Hope this helps.
Numerical IDs vs names
As an example, which of these would you choose for identifying a single transaction, from a single bank account, for a single company:
/companies/freds-painting-ltd/accounts/savings/transactions/4831
/companies/freds-painting-ltd/accounts/1/transactions/4831
/companies/62362/accounts/1/transactions/4831
You idiot, something totally different! Crikey, did you even READ Fielding's dissertation?
Now, I think the 1st one is the most readable. If I have more than one company, or if I'm someone like an accountant managing multiple companies, it's immediately clear which company, and which account, I'm looking at. It's also more bookmarkable/emailable and would prevent 'fishing' for other companies by changing the company ID. I would want transaction IDs to be unique to an account (I.e. Both 'savings' and 'current' accounts could have transaction '1'
A 'company' will be my 'top-level', or 'first class' resource. Nothing at all would ever be shared between companies. As such, it would be the ideal candidate for a shard (or 'ancestor'/'namespace' in Google App Engine parlance). So I'd only have to worry about the account names being unique within one company. Every company could have an account called 'savings'.
Not sure what the situation in the rest of the world is, though LTDs or PLCs in UK would have a unique name, there could be many 'Dave's Window Cleaning' businesses (what's know as a trading name).
The business owner(s) could potentially opt for the top level /company/company-name URI to be public, and contain some basic details like their website, contact details etc, but everything below that would NEVER be accessible by search engines.
So my thoughts/concerns are:
1) Is it reasonable, when someone signs in to add their business, to say "Sorry, 'Dave's Window Cleaning' business is taken. How about 'Dave's Window Cleaning Portsmouth' (Having taken their location in another field)? My worry with this is that, for a more well known company, you're giving away the fact that they have an account with you. Or that someone could use that form to search for names. Perhaps not a biggie.
2) The size of the company name. Would it be reasonable for a name like 'Dave's Window cleaning, gardening, and loads of other stuff'? Thus creating a URL like 'daves-window-cleaning-gardening-and-loads-of-other-stuff/'
3) How to deal with someone changing their business name - I would approach it by creating a new company with that string ID, copying over everything, then deleting the old resource. The original URI would return 404 rather than redirecting - as you can't guarantee someone else won't want to take the now unused name, or even if more than one person has used the same name in the past.
4) Should the 'real' unique ID be an number in the back end, and for every request to be handled by first doing a query for what company ID this name actually related to.
5) The impact of searching for a transaction in the persistence layer.
6) The possibility of URL rewriting, but then that wouldn't work cleanly in GAE, nor would it solve the issue of ensuring company names are unique.
RESTful webservice vs RESTful website
So, we potentially have this lovely RESTful webservice that the latest snazzy iphone/android app can use (delusions of grandeur). But what about the main website itself? I note, right now, that the URL I see at the top of my page is not 'RESTful': /questions/ask is an action. There is no 'ask' resource on the server. It's more the state of the page, the preparation for POSTing to /questions/ - or if I'm editing, PUTing to /questions/{id}
I also note that Stackoverflow has URIs like /questions/362352/name-of-the-question, and that the latter part can be omitted, and one will be redirected to it.
Should I host a completely separate webapp that consumes my lovely webservice (from the same domain)? Do I even need a separate REST server, or can I rely on content negotiation (JSON/XML) and HTTP verb to select the right method (I'm using Jersey), and return the right representation?
So I could have /companies/aboxo/ return the whole HTML page (using stringtemplate.org) if it's a GET /,text/plain or test/html, and JSON/XML for others?
But what happens for 'add/edit/delete' transaction? Would GET / /companies/freds-painting-ltd/savings/transactions/?template=add be ok (or GET ../transactions/352?template=edit), and that would return the right HTML?
Thinking about this last detail is driving me mad for some reason.
Comments, suggestions, outright ridicule - all welcome!
Marcos
Rails solves the "id vs name" problem by displaying both in the URL but using only the id to actually identify eg:
/companies/62362-freds-painting-ltd/accounts/1-savings/transactions/4831
ie - for the ones that have a "pretty url" the function that generates your path write both the id and the name... but for your router, where relevant: you strip off everything thats not the id.
incidentally, it means your customer could actually write whatever they like into the URL and it'd make no difference:
/companies/62362-i_luv_blue_turtles/accounts/1-your_mum/transactions/4831
and your router still just sees:
/companies/62362/accounts/1/transactions/4831
:)
For a cannonical URI I suggest just /transactions/{id} as I presume the transaction knows what the company and account is. Therefore, #4 :-)
Is SEO a concern? I presume you don't want random folks off the internet googling for X company's transactions?! Therefore, I would just keep names (which may change) out of the URI.