recently I have been working with symfony 4 in search of some solution for the creation of web services api-rest and I have found api-platform. After several days trying, because I do not have much knowledge of symfony, I managed to raise the API for an entity that I created by default. It turns out that now I have the doubt of how to add to the api methods other than those that are by default, say the put, the get and others that are already by default, I want to be able to add to my entity the methods that I estimate necessary and with the name that I want. Please I would appreciate your help with some form or some simple steps that allow me to add new methods to the api always keeping in mind that I do not have much knowledge in the matter.
try to avoid endpoint proliferation as much as possible, think REST
the recommended way to hook your own logic in API Platform is using the built-in events
if you really need to add custom endpoints, here is a dedicated documentation entry, but it should be your last resort (see 1/)
Related
This might seem stupid but I've had this question for a long while. I've been using ORO CRM DB and its API for a while now. Its really one of the good open source CRMs. I just wanted to know if I can use their database and create a Django REST framework around it and create the same functionality of what ORO API is offering.
I would rather build the API with DRF than learn PHP to get the functionality that I need. So is this question. Kindly help me in figuring this out. Thanks in advance.
TL;DR
Yes for read, but using application database is a bad practice.
Explanation.
In Oro codebase there is a lot of triggers (listeners, queue message emitters) that could be fired during the CRUD operations, you can't use another code base to just mimic it.
Actually you can try to use DRF for read operation, that is rarely trigger any events, but doing this (use external db that is tend to change) is a bad practice.
You can try to explain your use case to get more context of what you are trying to achieve.
We have a currently a large API which serves many different clients and apps. As we want to move forward, we are in discussion to split up our API endpoint into dedicated ones.
Our base-URL is like this api.domain.com/{apiVersion}
With this, we serve for example our main App and an Reseller App:
Users Endpoint: api.domain.com/v1/users
Resellers Endpoint: api.domain.com/v1/resellers/sales
Our Idea is to change that either into:
api.domain.com/users
api.domain.com/resellers/sales
or into:
users.domain.com
resellers.domain.com/sales
I didn't find any good best practices on that, so maybe some has an interesting link or some opinion on that matter.
My preference would be api.domain.com/..., as everything is an API and you dont have to change the base url, but the second one makes it more dedicated imho.
Thanks in advance.
It might be useful to review Roy Fielding on Versioning, Hypermedia, and REST.
Unfortunately, versioning interface names only manages change for the API owner’s sake. That is a myopic view of interface design: one where the owner’s desire for control ignores the customer’s need for continuity.
....
It is always possible for some unexpected reason to come along that requires a completely different API, especially when the semantics of the interface change or security issues require the abandonment of previously deployed software. My point was that there is no need to anticipate such world-breaking changes with a version ID. We have the hostname for that. What you are creating is not a new version of the API, but a new system with a new brand.
(emphasis added)
You can also review Fielding's slides from Evolve '13
I have just started to look at Azure Functions and one of my biggest concerns currently is validation.
I have only really looked at the CRUD operations so far, but there doesn't look like a way to easily validate data coming from the request or into the storage.
I have found this poco-validation and thought it might be useful.
I know this is kind of and open ended question but I'd be interested to see what others was doing for validation.
We recently added Function Filters to the underlying WebJobs SDK but that feature isn't fully exposed yet in Azure Functions (see issue here). Related to this, we're also considering support for validation annotations to be applied to your POCO types (issue here).
Until the above issues are addressed, we realize the story for validation isn't great. The recommended approach is to perform required validation in your function code calling out to shared validation helpers/code as needed.
In my company they tend to ask some extremly weird features, they want me to load dynamic language files, is there a way to solve this issue without having to rewrite the whole Messages provider of play framework, and instead use some files stored somewhere on the server to handle internationalization?
this could save me a month of work because i've already wrote a huge application (been working on it for a year now) and they want to make all the labels customizable by client.
any help, or any suggestions?
i'm using play framework latest version.
Sadly there is not really much customization options in the Messages API. One idea that might work is to subclass MessagesPlugin with a custom implementation of the api method and provide strings from the database there and then register that as a plugin in your app.
I have a very-simple php-based website.
I would like to add "subsribe for information" box and send it to some list-management tool.
I found that phplist is quite a good one. However, I don't find any api which allows me to subscribe users using ajax.
(I would like to avoid the pages of phplist in order to avoid confusion due to different design, and also I want the interface to be multi-language).
Of-course I can touch the code, but I doubt that it misses this feature, so I assunme I simply missed it.
Thanks!
Hopefully you have managed how to achieve this already. I have a different use case not requiring AJAX.
Anyway, I've found a script that tries to ease the addition of subscribers to your list. Maybe you could use it as the backend to support your AJAX request.
This is the thread in which the script is shared, as others have found it useful, also for unsuscribing users, even handling massive subscriptions/unsuscriptions:
http://forums.phplist.com/viewtopic.php?t=5009
Finally, be aware this code is using PEAR DB abstraction layer, probably I'm going to use this but without the PEAR package.
I look forward for what you could do through AJAX and this functions.