As documented here, the guidance when constructing FHIR URLs is that they are recommended to be case sensitive and that it is up to the implementers to define their behavior.
In that context, is there any specific requirement for resource names in URLs to be Pascal cased or is that also something that implementers can decide?
The resource names are expected to be the same as they're defined in the specification. E.g. "CodeSystem". While servers are allowed to accept "codesystem", "cOdEsYsTeM", "CODESYSTEM", etc. any system that requests those is non-compliant.
Related
The documentation for canonical states that it is "is a special kind of Business Identifier" but then goes on to say "The canonical URL serves as a stable logical identifier for the resource". I understand the difference between the two types of identifiers, but it's unclear to me which I am suppose to use for canonicals.
The canonical identifier is the stable URI assigned by the source of truth which is the sole mechanism of referencing the resource via the canonical data type - which is the primary mechanism of referencing canonical resources. It is a 'logical' identifier in that there is no requirement for it to resolve (though it's nice if it does). It is a 'business' identifier in that it can be shared by different instances on different servers and always refers to the same business object and isn't expected to have any correlation to the resource identifier of the instance on any given server.
Is there a way for us to define the policies of a GraphQL API, which is both machine-readable and human-readable, which contains a set of rules (in other words, a specification) to describe the format of the API? I'm not talking about the schema, but of a spec where we can add security-related details (for example, complexity value to be assigned per field and depth limitation values) or any other related details. Any thoughts or ideas? Or can we send all of this within the SDL itself?
For example, for REST APIs, we use Swagger to define information on how to define paths, parameters, responses, models, security and more. Is there a need for a similar approach for GraphQL APIs? Your response is highly appreciated
We are working in an approach to add policies to your GraphQL API and allow you to better manage it, especially as you expose the interface externally.
Part of the challenge is that as opposed to a REST call that can easily be differentiated from others, all GraphQL requests look the same, unless a deeper analysis is performed on the incoming query.
This blog post describes how we perform this analysis: https://www.ibm.com/blogs/research/2019/02/graphql-api-management/
if this is of interest let's connect!
As per my understanding you need a tool to make documentation for the APIs you have build for parameters and so on.
If that's what you are searching, there is like swagger for GraphQL - Swagger-to-GraphQL
Hope that helps.!!
I'm working on extracting patients info in FHIR server however, I've came across two types of searching methods that were somewhat different. What is the difference between the search method of
Bundle bundle = client.seach().forResource(DiagnosticReport.class)
.
.
and
GET [base]/DiagnosticReport?result.code-value-
quantity=http://loinc.org|2823-3$gt5.4|http://unitsofmeasure.org|mmol/L
It's very confusing as it seemed that there isn't much that is mentioned about these two search methods. Can i achieve the same level of filtering with the first method compared to the url method?
The first is how to perform a search using the Java reference implementation. The latter explains what the actual HTTP query looks like that hits the server (and also specifies some additional search criteria). Behind the scenes the Java code in the first example is actually making an HTTP call that looks similar to the second example. The primary documentation in the FHIR specification deals with the HTTP call. The reference implementations work differently based on which language they are and are documented outside the FHIR specification on a reference implementation by reference implementation basis.
I'm thinking about using IsBadCodePtr to distinguish a predefined resource type from a custom resource type name.
Is it good practice (or even the best method?) to use the IsBadCodePtr API to find out if a given resource type belongs to one of the predefined resource type or is there a better alternative?
Please note that I'm talking about resource type names and not IDs.
It is not good practice. You should instead use the IS_INTRESOURCE macro, which tells you if a resource pointer was created with MAKEINTRESOURCE (which means it isn't a real pointer). Note that this doesn't definitely mean it is "predefined", because you can call MAKEINTRESOURCE on your own resource IDs.
The IsBad____Ptr functions should not be used in general. As the documentation says:
This function is obsolete and should not be used.
There is more information in this blog post by Microsoft's Raymond Chen: IsBadXxxPtr should really be called CrashProgramRandomly.
The apiary.io list resource attributes in point form. Is there a specific convention to show what data type these attributes are, or met data specifying formats?
At the moment there is not convention for discussing resource's attributes in the API Blueprint. What comes close is planned Message-body Attributes Description.
But I feel what would be the real solution is what the concept of a future API Blueprint – Resource Blueprint proposes under semantic data definition (of a resource). Refer to the example resource blueprint.
So while none of the previous is implemented, if you are looking for a convention, I would suggest consider the one as proposed in resource blueprint e.g.:
# Resource [/resource]
## Attributes
+ ip (string) ... ipv4 or ipv6 address associated with the resource
+ some-other-attribute (number, optional, `42`) ... a number of something