I have a REST API that I'd like to port to run as a collection of cloud functions. I'm wondering how to split up the different endpoints in the best way, and how much to rename endpoints to fit the GCF model.
For example, I have the following types of request.
GET /images
GET /images/<image_id>
POST /images
If this was implemented with GCF, these would all fall under the same function images, and then I would need to implement some routing based on HTTP method, plus a pattern match for <image_id>, etc..
I could however choose to implement something like...
GET /images
GET /image/<image_id>
POST /createImage
...so that each endpoint has a distinct function that is invoked. This seems more appropriate from a cloud functions point of view, but not at all appropriate from a RESTful design point of view.
What are the trade-offs for implementing cloud functions in one or the other of these ways?
Related
For example, I have https://REGION-FUNCTIONS_PROJECT_ID.cloudfunctions.net/myfunctionname
But I want to have a root link to my function. Something like that:
https://myfunctionname.REGION-FUNCTIONS_PROJECT_ID.cloudfunctions.net/
How can I get this?
You can't change the URL provided by Cloud Functions, but you can use Firebase Hosting as a proxy to Cloud Functions so you can use a custom domain to access functions deployed to the same project.
https://firebase.google.com/docs/hosting/functions
Currently there is no way to get a different URL from a Cloud Function other than the one automatically generated which will always have the format "https://REGION-PROJECT_ID.cloudfunctions.net/hello_get".
If there was a way to do this, it would need to be defined during ht deployment of the function, and according to the documentation for 'gcloud function deploy', there is no way to specify a way to change the URL generated.
I've been searching around for the past few days trying to find a good article that addresses what I'm trying to do, but haven't really found much yet. Most point me in the direction of pre-existing C++ MVC frameworks.
I have a C++ application with a tiny embedded web server that responds to HTTP requests. What I want to do is create a routing pattern in which I can define service end points and the application will be able to use the proper C++ controller class.
For example, I could define my service end points like the following in a text file:
POST /login UserController::login()
GET /user UserController::get()
GET /dashboard DashboardController::get()
And have the C++ application call the appropriate class and static method based on the service I'm invoking. So in the case of the above example, if I submit an HTTP POST request to /login, then the Router should invoke UserController::login(). Service end points don't necessarily have to be defined in a text file, there could be another in-memory data structure they can be defined in.
I've been considering something like the Proxy pattern: http://en.wikipedia.org/wiki/Proxy_pattern
Or I was looking at this pattern: http://gameprogrammingpatterns.com/service-locator.html
Before going too far down a specific implementation I wanted to get some feedback from others on how they might go about implementing such a requirement?
Thanks!
I know how mythz generally feels about HATEOAS, but let's say that I have to follow the HATEOAS principles in my REST services and add links ("self", "parent", and other possible relations) to my DTOs.
Links like "self" and "parent" contains paths to the resources and those paths are of course related to my routes.
I'm using the following project/deployment structure for my ServiceStack REST service. If that matters, I'm using ServiceStack 3.9.71.
Service Gateway Assembly:
defines my DTOs. Each DTO has a factory creating that DTO from the corresponding domain object
defines operations and their routes
Service Implementation Assembly:
uses ServiceGateway to get DTO definitions and access their factories
does whatever domain logic requires and create the corresponding DTOs through the afore mentioned factories
Service Interface Assembly:
define my REST services and
calls ServiceImplementation from ServiceStack's HttpHandler, according to REST verbs (GET, POST, ...)
WHERE would be the proper place to add link information to my DTOs?
Option1:
In my Service Gateway, when I build the DTOs themselves. It seems logical:
I know what I need to know about my domain objects and I can easily
build the links. Except that my DTOs are now all including an
additional member (Links) and building those links forces me to
explicitly provide paths/routes (i.e. hard code them). Seems to lead
to a maintenance nightmare.
Option2:
In my Service Interface assembly, where I have the request context and
I know my routes. I can encapsulate whatever my Service Implementation
returns in a meta-object containing the response and a link
collection. However, to build that link collection, I sometimes need
information available at the domain (i.e. Service Implementation)
level. The big "con" side for me is that it creates a new additional
and artificial level in all my responses. Could be seen as a way to
standardize response formats but I don't like it.
Option3:
My hope is that I can write a wrapper generically "injecting" a "Links" member to all the DTOs
I return by hooking somewhere into ServiceStack in my Service Interface assembly. I haven't
investigated much in that direction because I feel I could be wrong on
the whole approach here.
Any advise / suggestion welcome. Thanks to all.
I'm not sure If I'm suggesting you option1 or option3, but this Is what I came out after trying to do the same thing.
I started from this answer.
Now you can access route metadata directly from filters.
So my current approach is:
=> Services create the dto responses and the next collection of hypermedia links that will be attached to the response. In this level you know the "operations" by type but not "how" you will build the routes. I think it is coherent that domain level deals with workflows of operations.
=> Within a response filter I get the available routes from Metadata, and build the routes from dto properties by convention. Finally routes are added to http header.
Caveats:
I'm mapping 1 dto - 1 route. This approach could be more difficult in other cases.
I'm in a process of migrating Rails project into Django. Rails project was built using restful routes and it never touches the database. Instead, it simply redirects to different methods which all call an external service with the specified action method. Now, I have found a number of frameworks for django that provide restful capability plus a bunch of bells and whistles, but it's an overkill for my current case.
As an alternative, I can ignore action method in urls.py by simply providing a regex to validate urls and then parse the request method in views.py, redirecting to the appropriate method. Is this a way to go or are there any other approaches that I can look at?
Class based views look like the idiomatic way to organize restful view functions by request method.
Django snippets has several simple example implementations.
I have just read Resource-Oriented Architecture: The Rest of REST. The reasoning behind content negotiation is compelling, but there's one thing I sometimes need, which seems to be impossible in this schema.
Let assume I've got a web service to deliver some graphs. I want users to choose between different styles of these graphs (a fancy color one, B&W, ...), but all of them are always png images. For all of them the mimetype will simply be image/png. So what is the preferred way to negotiate custom parameters?
Use querystring parameters.