I am using a JSON Schema to validate a file. This is somehat similar to an XML XSD.
I have a few questions concerning the id field.
Does the schema still works without network connection ?
The URL in the id should be accessible from a web browser ? i.e. if 'id' = "https://example.com/question", does this mean that we should be able to access the schema from a browser by going to https://example.com/question ?
I am a bit lost on this subject. I know that it is best practice to have an id property as a unique identifier for every schema, and that this gets most useful when creating a complex schema with different schemas that reference each other.
But I am not sure if we need to assign a URL to the id field or not. And I'm also lost concerning the implication of having this URL for the schema.
Thank you very much for your help
Main purpose of id ($id since draft-06) is to organize scope for $ref resolving.
$id does not have to be an existing HTTP resource. Identified schema can be even defined in another one (example in spec test suite).
JSON Schema spec expects that validator should be able to resolve references based on $ids defined in current schema. Remote references should be also resolved, but there are no limitations on how exactly it should happen.
In many cases network interactions during validations are very unwanted due to high latency. Most implementations provide you a way to preload/define schema resources by $id explicitly before validation.
According to spec root schema SHOULD have $id which is an absolute URI, but whether or not it should be accessible with HTTP client is up to you and your validator.
$id is only defined to be an URI.
http://json-schema.org/draft-07/json-schema-core.html#rfc.section.8.2
See RFC-3986 Uniform Resource Identifier (URI): Generic Syntax
https://www.rfc-editor.org/rfc/rfc3986
"A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource."
A nice write-up by Daniel Messier provides a clear explanation of the nature of an URI - which can just be an URN - but may also be a valid URL
https://danielmiessler.com/study/url-uri/
Related
What's the difference between using : and ? in a URL? For example /products/:id and /products?id=1? I am trying to get the values from the URL like this Product.findById (req.params.id) but I was wondering which one is most suitable. I know using : do I have to use req.params and ? req.query but I don't understand the difference between them, are they the same?
in my point of view, it is totally different if you are using RESTFUL API pattern
/products/:id called path parameters
The path parameters determine the resource you’re requesting for. Think of it like an automatic answering machine that asks you to press 1 for service, press 2 for another service, 3 for yet another service and so on.
Path parameters are part of the endpoint itself and are not optional
but query parameters
Technically, query parameters are not part of the REST architecture, and they used to help you completely understand how to read and use API’s Query parameters give you the option to modify your request with key-value pairs.
Having your parameters in the query is conceptually optional to the router, query parameters are more of properties and descriptions of the request itself, like when saying GET /users?sort=asc, in this case, the sort attribute was more of a description to the request and the request could complete the fetch without it, that might not always be the case, but a query parameter still describes its request even if it was mandatory.
On the other hand, URL parameters are part of the request itself, the URL without the parameter doesn't make sense, like GET /users/:userID, in this case, not supplying userID will supply unexpected data (A list of users for example) if it didn't break the router completely. URL parameters play part in defining the request rather than just describing it, and they can't be optional.
When trying to query for a specific DOI attribute using the following URL:
https://api.labs.cognitive.microsoft.com/academic/v1.0/evaluate?model=latest&count=10&offset=0&attributes=Id,Ti&expr=And(Composite(DOI='doi:10.1594/PANGAEA.667386'),Y=[2000,2009])&subscription-key=SUBSCRIPTION_KEY_HERE
I get the following error:
{"Error":{"Code":"Bad Argument","Message":"Invalid query expression\r\nParameter name: expression"}}
However when accessing using a different attribute, e.g. journal ID as below:
https://api.labs.cognitive.microsoft.com/academic/v1.0/evaluate?expr=And(Composite(J.JId=114840262),Y=[2013,2015])&model=latest&count=10&offset=0&attributes=Id,Ti,J.JN,J.JId,Y&subscription-key=SUBSCRIPTION_KEY_HERE
It works fine! Why does the behaviour of the API only work with some attributes? What am I doing wrong?
Relevant documentation I've read:
https://learn.microsoft.com/en-us/azure/cognitive-services/academic-knowledge/evaluatemethod
https://learn.microsoft.com/en-us/azure/cognitive-services/academic-knowledge/queryexpressionsyntax
Not all entity attributes can be queried for/matched against; some can only be requested as part of the result when querying against other entity attribute fields.
You can reference the Paper Entity documentation to see what query operations are available for different attributes. For example citation count (CC) does not support any matching operations, hence the "none" in the "Operations" column, however journal name (J.JN) supports the equality operator.
Unfortunately, DOI is part of the "Extended" attributes, none of which support matching operations.
It seems that /patient/123 and /patient?id=123 will both work fine at the backend of my application.
I could do req.param.id and do req.query.id as well.
But I'm getting confused on when to use then. What are the cases that you should use params and what are the cases that you should use query. Because in the answer here, j_mcnally only mentioned that they're interchangeable.
Url params and url path are somewhat interchangeable. People usually use url path for describing restful resources...
So what are the possible pros and cons of using them.
The query string is usually modifiers to the resource you're running, while the path should give just enough info to let your back-end indentify the data you're requesting.
/patients/123 - patients in this case would be the namespace, and 123 would be the identifier. You can also extend this with:
/patients/123/profile where profile would be an identifier for a pre-defined collection of data.
Query string usually offers fine-grained control over what and how your resource presents data, for example:
/patients/123?fields=firstname,lastname,age - This is pretty self-explanatory, but basically the query string in this case modifies what data is returned.
/patients?orderby=age&order=desc&fields=firstname,lastname&limit=25 - This query string modifies both how and what data is returned, and that's the purpose of the query string in RESTful API's.
In reference material for CouchDB and Couchbase it's common guidance to store the type of a document as a parameter within the actual document.
I've got a database, where I have different documents that record certain behaviour by URL. So naturally, I use the URL as the id of the document.
The problem I find is that by using just the key as the document id, I now get clashes between documents of different types. So I have started using the type as the first part of the key like this:
{ doc._id: "rss_entry|http://www.spiegel.de/1234", [...] }
{ doc._id: "page_text|http://www.spiegel.de/1234", [...] }
Now I start to wonder why I've never seen this approach to model type in any of the documentation.
Prefixes are commonly used. In addition to support for scenarios such as yours, prefixing allows one to perform logical range queries against views. There is use of this technique in the modeling examples, but perhaps the concept is not described in as much detail as you are expecting. In the section http://docs.couchbase.com/couchbase-devguide-2.5/#modeling-documents, the documents are keyed as beer_NNNN and brewery_NNNN. Also, the section http://docs.couchbase.com/couchbase-devguide-2.5/#using-reference-documents-for-lookups goes a bit deeper into this technique. There is a counter document named user::count and then each user is keyed as user::NNNN. Additionally, there are documents in the example that are keyed as fb::NNNN for a Facebook ID, email::XXX#YYYY.com for a user's email address, etc.
I have an XML Schema referencing two other schemas where the same element is declared twice resulting in an invalid schema.
Is there any built in XSD construct allowing me to handle this situation by ignoring one occurrence or is this situation just fundamentally wrong?
That's fundamentally wrong - a schema is specifically intended to make things clear and unique. You need to address that somehow - XSD has no way of ignoring something that's in the schema - anything in the schema file must be valid.