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
Related
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/)
I don't even know if this is even possible, but I thought I'd ask.
I am creating a small CRUD application but I have multiple sites. Each site would use the CRUD. The application would have common CRUD methods and style, but each individual site would apply different forms. I want to avoid creating multiple CRUD applications that varied only in specific content (just different forms).
I want to have something like this:
mycrud.website1.com
mycrud.website2.com
mycrud.website3.com
I can create a subdomain for each individual site no problem. But is it feasible to point all the subdomains to one MVC application directory? And if it is possible any suggestions for how I might go about restricting users from website1 from seeing website2 or website3 content? Is that something "roles" could take care of (after authenticating user)?
Thanks.
There are a lot of websites that do this, not just with MVC. Some content farms point *.mydomain.com to a single IP and have a wild card mapping in IIS.
From there, your application should look at the URL to determine what it should be doing. Some CMS systems operate in this manner, using the domain as a key to deciding what pages to load.
I've built a private labelable SAS application (Software as a Service) that allows us to host all of our clients in a single application. Some clients have customizations to pages or features. We are able to handle that by creating custom plugins for each client that over-ride the Controllers or Views when needed.
All clients share a common code base and aside from each clients custom theme/template they are the same. Only when a client had us customize one feature did we need to build out their plugin DLL. Now, this is advanced stuff so it would require heavy modifications to your code base but in the end if it's what your application needs it is 100% possible.
First - the easy part is having one web site for all three domains. You can do that simply with DNS entries. No problem. All three domains should point at the same ip.
As far as the content, you could do that in a number of ways. I think your idea of roles is pretty solid. It also leaves open the possible of a given user seeing content from both site1 and site2, if that would ever be necessary.
If you don't want to force users to authenticate, you should look at other options. You could wrap your CRUD logic and data access logic into separate libraries and use them across three different sites in IIS. You could have one site and display content based on the request URL. There's probably a lot of other options too.
As often happens, I have a nice solution to one problem, which unfortunately causes another.
We have an app that provides services to members of various organizations, parts of a larger parent. The organizations require custom URLs. So, members of org A access the URL https://server/vdir/OrgA, and members of org B access the URL https://server/vdir/OrgB.
Both of these would map to the exact same area, controller, and action in the app, although they might look different to the end user due to some custom view content.
Because the list of organizations using this app is dynamic, and because not all organizations will start using it at the same time, I started out setting up the route mapping programmatically. In the target Area, I override the RegisterArea method, pull the active organizations from the database, and execute a custom context.MapRoute call for each.
Doing it this way avoids another problem, which was that the the URLs that have the organization sitepath ("OrgA") in them look exactly like those that have a meaningful area name in them, which actually does map to an area. Treating the organization sitepaths as virtual area names and explicitly mapping them to the target Area avoided certain misdirections.
And this works, nicely. But: it's all executed at Application_Start. If we add an organization, it doesn't become active until we restart the app, which would be highly disruptive to anybody who was using it at that time.
So my questions are two:
Is there a better approach than mine for doing this? I did research the problem, but the relevant keywords are so ubiquitous that it was a bit of a needle-and-haystack situation.
If there isn't one, is there a way to refresh the route mappings without restarting the app?
Phil Haack wrote an article dealing with exactly this problem.
The really, really short version of which is that you place your route registrations in a file other than Global.asax and cache the contents of that file. The cache has the file as a dependency and calls a method when the cache is invalidated (read: file is altered) that re-registers your routes.
I have an application that handles licence registrations for various product. I'm currently re-factoring into a basic MVC framework (not using any of the big ones yet). We have various basic scenario's e.g. someone can make a cc purchase of a product via the website. This fires the create customer, create order, create licence etc objects (basically just db inserts using beans and gateways as I think that is the "standard"?).
Anyway, to handle all this I'm calling a purchaseService.cfc, which validates the various business rules and wraps the persistence(db) layer processes together. That seems to work fine and I thought having a purchaseService cfc contained that process well.
Now we need another, similar process where a key can be "registered" to achieve the same as above. i.e. provide a licence to the customer. (obviously there will be differing rules).
As far as naming conventions go, are there any rules to help decide what to call these service "wrapper" type cfc's. Most of the examples I see are per object, e.g. the user object has a userGateway and userService and don't give examples of cases where we need a wrapper to call multiple objects. Is what I've done ok convention wise using a purchaseService object? (I was going to call it CustomerlicenceOrder.cfc based on the other objects it was dependent on. What will I do with the new requirement? Perhaps create another service object? Called PurchaseByKeyService? Doesn't sound right to me. I have read so much on OO and MVC etc etc but the more I read the more questions I have :)
Thanks
There's certainly nothing wrong with grouping actions into a common service. In fact, it's usually more accepted than just creating standalone services for each domain object.
Read more on the Service Layer pattern if you're interested.
I have built a little Web UI for Pidgin(respectively all libpurple based messengers) together with DBus and Sinatra.
It was for fun and learning purposes and now I'm looking for ideas to extend it.
Can you think of any useful applications or extensions for it?
Since I work on this project to learn something new, ideas for other technologies to be used/combined are welcome.
Finally here is the link: pidgin-web-ui
I few things that that might use to many many people would be:
good and simple to configure https support, so that users in "monitored" countries to be able to still chat freely (if the server is somewhere else).
Unified Message Archive . Many IM clients have various archive functions, but are different, limited, hard to search, and many are "client only", so not accessible when one needs them the most. Since Pidgin can connect to so many IM networks, it would be cool to have such a "global message hub archive". This would ensure that everything the user is talking is archived (very useful for businesses too), easy to search, available on a server (so always at hand).
File Archive on the server. The same as the Unified Message Archive, but for the files/images users exchange. Having them on the server (with a hash for easy sync) as a backup and archive would greatly reduce the traffic if they need to be shared more than once.
The would be many more nice features, that would help many users, but the above 3 seem to miss from usual IM software.
My idea after a brainstorming minute:
Dropbot
Create a messaging account anywhere and add this account as a contact to your messenger. This contact is your Dropbot.
Change your interpreter UI so it does not display a conversation but a log. In this way you can just drop things to the contact like interesting links. There could be a Dropbot for a read later queue, your favorite citations or for a list of funny findings.
You could then extend your UI to a little mashup. It could follow the links and grap the title of the page and a content preview just as Facebook does it when posting a link to your wall.
You could further extend your app by adding post-drop behavior to the Dropbot.
Dropbot could post your link (probably with a message) on Twitter or Facebook.
Dropbot could automatically distribute the link to the other contacts of it (like your friends)
Ok, that sounds fine... but you could do that without a message bot inbetween. What's the deal?
For me the advantage would be that my IM is always open and it would be fairly easy to drop a link. You could do the link dropping with Delicious or post stuff to a Google Wave, yeah. But I don't like to go to a web page, log in and organize stuff in the UI. Actually I stumble upon those links when I should do more important stuff instead. So just dropping it to my IM Dropbot contact would be cool.
Why not extend it to cover all the basic features of instant messaging (sending/receiving messages, adding contacts, etc...)? Seeing how many features you can reproduce may be a fun exercise. Create your own little Meebo...
Want to have fun?
Make a Markov-chained-based chatbot integrated into the web app. Make it use scraped web search results for the content, after searching for terms parsed out of the human's responses. That should be fun, and will give you funny, and sometimes eerily smart-looking results. Have fun!
I have seen your code. Why not split dbus_thread into a event_machine daemon for further scalability?
Integrate it with Twitter. Trace conversations (#Replies), including multi-party involvement. Log them. And so on.
Many interesting features and a popular, original API to learn.