Documentation for DS.ActiveModelAdapter is exists only for 1.13 (for 2 - 404:
https://api.emberjs.com/ember-data/1.13/classes/DS.ActiveModelAdapter
So, it looks like it's moved out from DS:
https://github.com/ember-data/active-model-adapter
We have ember-data 2.13.2 and it's working fine with active-model-adapter
But we got some issues with the bump to ember-data 2.14.11 with nested behavior
The big issue here is to rewrite the backend part.
We also may use RESTAdapter:
https://www.emberscreencasts.com/posts/113-restadapter-vs-jsonapiadapter-vs-activemodeladapter
but it looks like ember way is JSONAPIAdapter way:
https://api.emberjs.com/ember-data/release/classes/JSONAPIAdapter
So, generally, the question is: what way is better for ember-upgrade?
keep backend API and maintain active-model-adapter
rewrite backend API and migrate to JSONAPIAdapter (with data/relationships approach)
rewrite backend API and migrate to RESTAdapter
keep backend API and implement custom serializer to change on the fly input/output to use JSONAPIAdapter or RESTAdapter (pick best) logic on FE (maybe it's some crazy way, but it's just to ask)
Note: backend API on RubyOnRails
A rewrite of your backend is not needed. Ember Data is flexible enough to handle all REST APIs that follow some convention among their endpoints.
Let's have a look on your specific use case.
ActiveModelAdapter and ActiveModelSerializer were deprecated in Ember Data 1.13 and removed in Ember Data 2.0. But the logic itself is still available through active-model-adapter package.
All that package does is providing a customization of Ember Data's build-in RestAdapter and RestSerializer packages. If you ignore the in-source documentation it's actually not much code. You can find it in the addon/ folder of active-model-adapter package.
So even if this package would not be available you could still customize RestAdapter and RestSerializer in the same way to support your backend as is.
Related
I am wanting to use Nuxt3. From my understanding, it uses universal rendering, which is like a cross between CSR and SSR. I have a few questions, however, before I get started.
How does Nuxt3 determine which code is executed on the client-side vs. the server-side?
If I wanted to use JWT auth, will Nuxt3 know that this would be stored on the client-side?
If I wanted to use Pinia as my state management library, which will manage state in the client, how would Nuxt3 be able to distinguish that?
What about API requests or using 3rd party realtime services like
Pusher?
[assuming that you do have ssr: true in your Nuxt config file]
Nuxt runs your app in an isomorphic way, meaning that most of the code should both run on the server and on the client.
Here are all the various hooks available for Nuxt3, and an explanation as of where they are supposed to run (server, client or both). This lifecycle for Nuxt2 may be useful because it's more visual overall.
Note that some parts of Nuxt can be exclusive to the server (server routes) or client (middleware).
Depending on how you use and implement your JWT, you may give some hints to Nuxt. Assuming that you want to use it as a plugin, you could have:
/plugins/myPlugin.ts to have it isomorphic
/plugins/myPlugin.client.ts to have it only on the client side (reciprocity for the server.ts suffix)
It all depends if your package/implementation can be isomorphic or not. There is no need to have everything running on the server if there is no benefit.
Please also note that some code can only run on the client (using window) or on the server (using fs).
You can also of course use some dirty conditional like if (process.client) { ... into an isomorphic place (middleware, composable, etc).
Pinia would probably be used with it's Nuxt module, so you don't really need to worry about it running on the server or the client. I'm not sure if there are parts that could run on both btw.
If there are such situations, don't worry: the core team of Vue have already done that work for you.
Too vague of a question, I'd say it depends. You need to take that decision, based on how a given NPM package works and what you do want to achieve with it.
If it supports a server, that would probably be faster there rather than on the client.
For things only available on the client, you can import it globally with a client side-only plugin, or import it into a local component + make a conditional (or use a lifecycle hook that is run only on the client).
I have undertaking a master thesis project that uses the openapi.yaml files to auto generate test for REST-api web-services - This has lead me to host a local instance of gitlab, so that I can run the tool I am working on, on gitlab. For that to happen I need the .yaml files containing the documentation for the API calls. Such files are found within in the gitlab source-code, but the call does not seem to work.
Some calls work, namely:
http://localhost/api/v4/version
http://localhost/api/v4/users
http://localhost/api/v4/projects
http://localhost/api/v4/groups
all returns meaningful JSON.
the problem is that a lot of the calls within the documentation does not work (returns a "404 not found"), namely:
http://localhost/api/v4/metadata
http://localhost/api/v4/projects/{id}/access_tokens
and more calls specified in the documentation.
The problem is that a lot of the calls that work are not documented (all of the above except the 'version' call). I have really tried to look for an alternative openapi.yaml files, but with little success and I am also puzzled to why the one left in the actual source-code does not contain meaningful documentation. Have I overlooked something? I am currently using postman and providing a sudo authentication-token.
Thanks in advance - I must surely have overlooked something!
Currently I have tried to look for an alternative openapi.yaml both by googling and be browsing swaggerhub.com. I Have look at the documentation pages for gitlab, but I have not found anything I did not already have.
Unfortunately, at this time of writing, GitLab does not provide an OpenAPI spec for all of its API. Only a very small part of the API is documented in openapi.yml. There is an open issue that is tracking this improvement.
For now, the online API docs are going to be your best source of information available on using the GitLab API.
As for your problem of getting 404 responses, the most common cause of this is that the credentials you are using do not have permissions to the project/feature you are trying to access or you are not using a proper authentication method. Also keep in mind some features of the API require an appropriate license entitlement.
I am learning express and the http methods, but I cannot find any documentation on it. Is /api/value just for the json data, like an address just for that data? Just any extra info on it would be appreciated. Like what exactly does it do and if there is any documentation from express about it. Or is this a global term used in urls throughout frameworks and the internet?
For example:
app.get('/api/jackets'(req, res) => {res.send('logic')})
Why do we need to add the api before jackets and what does it do?
It's not necessary, it's used only for a better understanding
The /api request is not required, but putting a prefix in front of the API requests such as:
/api
or, in some cases including a version number:
/api/v1
Allows you to use the same web server for more than one type of request because the /api prefix uniquely identifies each API request as an API request and it can easily be routed to where you handle API requests. You could have plain web page requests from a browser served by the same web server. While, you don't have to use such a prefix, using it gives you the most flexibility in how you deploy and use your server.
Similarly, putting the version in the prefix such as /api/v1 allows you to evolve your API in the future in a non-backward-compatible way by adding a new version designation without breaking prior API clients (you support both versions at the same time - at least for a transition period).
I'm a new to RESTful API's and sort of developing my first one at the moment for a mobile application to be followed. I have a question regarding API versions and how to manage/tackle them.
At this moment, my API 'version' is a directory named v<version_name> in which my API class resides. In that directory, I have resources that the API and REST client needs in another directory named include. So the structure is as follows: example.com/api/v0.2/method_name/ and on .htaccess, I'm making sure that everything that follows the API version (hardcoded in the .htaccess file, is saved in a query string parameter).
I'm not sure if it is the right approach for a live application as it requires manually changing the URL endpoints at clients' ends, too. So my questions are:
Is this the right approach to API versioning?
If it is and I keep it, how do I deal with outdated URL's. Say for instance the app is live and I update the API to v0.3 but the client who have the app installed would be accessing v0.2 and getting a 404 response code back?
Is there more elegant solution out there? It must be.
Edit: there are some resources that reside outside of the api folder itself, in the root include folder so to speak.
Edit 2: My API is targeted to be consumed by mobile applications and is not publicly consumable.
While I think these questions are primarily opinion-based, I will have a go...
I think it is a valid approach, and I've seen others use it,
including Microsoft.
When it is necessary to outdate an API, you could give a 404
back with an explanation that the new API is at the new address.
HOWEVER it is usually a bad idea to just retire an API version; you
would at least have to give client developers enough time to switch
to the new API before retiring the old, if at all.
A more elegant solution would be to just keep the API at one
address, and update that as necessary, and add to it rather than
replace whenever possible. Keep supporting outdated functions for as
long as possible and have open communication to client developers
about when a certain method will no longer work.
Just my opinion, do with it what you will...
I've been looking at backends and APIs for a while now. It seems that sometimes devs will build a regular backend (in say a language like PHP) that handles all the backend matters and sometimes devs will instead choose to build out their backend through an API and then use their own (and possibly other) sites to pull data from this API.
I was wondering this:
Say I want to build a regular backend using a server-scripting language like PHP, which I will use to not only render my main website, but will also allow me to do other server-side scripting etc. Then say I want to use this data from the current site and make it accessible to another site of mine through API calls. Will it be possible to build an API on top of a regular backend?
If the answer yes, how complex can it get to achieve something like this?
What tools or design strategies (if any) would you have or have used for achieving this?
This is an old question, but since I'm here, I may as well provide an answer for anyone wondering. Joe is asking about server-side web APIs versus regular server-side code.
Yes, you can have a "regular" backend and an API backend exist at the same time. If your backend is in PHP, you can refactor and extend your code to handle API requests.
Like Patrick Evans said, an API is the backend. If your backend PHP code communicates with a database to manipulate or retrieve data, then you can consider this an API transaction. Whenever your backend receives a request, evaluates/actions that request, and returns a response, it is essentially acting like an API.
Let's say you own example.com, with an index.php file in the root directory - so when a user requests example.com in their browser, this index.php file is processed and served to them. Now, you can set up this index.php file to handle both regular page requests (i.e. the php script returns an html template that is rendered by the browser) and API calls. This can be as complex or as simple as you want it to be.
The best way to handle this would be to assign different routes for rendering your main webpages and API calls. You can set up routes in the following way...
example.com/index.php?route=api&data=users can be handled by your 'API code' in index.php to return a JSON response containing a list of all the users in your database, while example.com/index.php?route=home will just return your website's home page.