I've been developing REST API using springboot and came across situation like API needs to maintain some reference data table eg : consumer will request with a particular key and that key will be interpreted inside the API by looking up reference data my question is from below methods which are the best way to handle this if none of these proper methods what are the suggested ways.
Have reference data in the database as a key-value pairs - modification is cons
Have it inside the project as an XML data file - not centralized modification on multiple places
3.Have it inside the JVM as the static data load on app bootstrap
further, this is open for you all to suggest me any additional ways or most optimum way
Related
I try to sync data via GraphQL from my backend. Therefore I use the artemis package to generate my classes. However I then want to cache the data localy and therefore use the sqfentity_gen package to generate classes to safe my data via sql. I can use a json constructor with each framework to convert the data between.However I want to encapsulate certain functionality since I dont want to just safe changed data localy but sync it to the backend and handle certain errors like merge conflicts or missing network. Therefore I am thinking about wrapping the classes with an other one since I cant change the generated code. Is this a good idea or are there other solutions which work better? Would you use a completly diffrent setup? Glad for any suggestions
Instead of generate and/or re-generate (update) classes which are based on db-tables (I assume), you can use solution from the box, in example, NReco.GraphQL
It allows you set db-schema in the json file and just set db-connection. If you have a lot of tables, you can just generate that json file based on metatable info.
Storing and updating classes, from my point of view is useless.
I'm working on my first client-server project and using REST.
So my question is where and how do I handle the data.
Options:
Define a datamodel and share it to the server and client. So I could you use JSON and object transfering, but each change of the datamodel requires also possible changes in the server and client implementation.
Simply transfer the data as basic data types (strings, boolean etc.). So only a datamodel is required in the client.
What do you recommend?
As you want to develop REST APIs and REST evolves around resource representations so first option (define data model) is way to go.
Note that all data model changes will not break the APIs and thus client implementations. Only when you re-structure your resource representation OR you take out one of attribute from model - that's when you will need to version your APIs.
I'm in the process of developing a custom datasource to interface with a REST API. In the example provided on the CakePHP website they return the data from a READ operation in this structure:
Array(
'ModelName'=>Array(all the actual data here)
)
The code looks like:
return array($model->alias => $results);
Is there any specific reason to return the results this way or can I just return as:
return $results;
My concern is that if I don't return in the CakePHP specific format I might not be able to use some other built in functionality. I don't see anything specific about the need for this structure. Any insight would be appreciated.
It comes down to CakePHP's data structure guidelines. The reason Cake uses the model name as the array key and the results as the value is because it makes it very easy to read when you have multiple tables returned in the same query - after all, Cake models are relational database maps and are built to be associative.
How you use the results from Cake's data results is up to you. Yes, there are times when the model name prefix annoys me and I find it useless, but most of the time it can be very useful to help you distinguish between multiple associated table results in one query.
If you don't think you'll ever need this and don't mind breaking Cake's data structure conventions, there's nothing wrong with breaking away from it - but if I were you I would create your API interface in a way where it conforms exactly to the structure that their built in datasources return (for current and future compatibility reasons mainly).
More info on creating a REST API datasource is here in the manual.
I am working on developing a set of assemblies that encapsulate parts of our domain that will be shared by many applications. Using the example of an order management system, one such assembly will contain all of the core operations an application can perform to/with an order. We are applying a simple version of CQS/CQRS so that all operations that change the state of the "system" are represented as public commands, such as CancelOrderCommand, ShipOrderCommand and CreateORderCommand. The command handlers are internal to the assembly.
The question I am struggling to answer is how to best expose the read model to consuming code?
The read model will be used by consuming code to perform queries. I don't know how all of the ways the read model will be used so the interface needs to be flexible to allow any query.
What complicates it for me is that I not only need to expose my aggregate root but there are also several "lookup" lists of related data that client applications may use. For example, each order has an associated OrderType which is data-driven (i.e., not an enum) and contains several properties that will drive some of our business rules that control what operations can/cannot be performed, etc. It is easy inside my module to manage this relationship; however, a client application that allows order creation will most likely need to display the list of possible OrderTypes to the user. As a result, I need to not only expose the list of Order aggregates but the supporting list of OrderTypes (and other lookup lists) from my read model.
How is this typically done?
I'm not sure what else to explain that will help trigger a solution, so please ask away...
I have never seen a CQRS based implementation expose a full dataset for ad-hoc querying so this is an interesting situation! In a typical CQRS scenario you would expose very specific queries because you may want to raise events when they are called (for caching for example - see this post for more details on that).
However since this is your design, let's not worry about "typical" or "correct" CQRS, I guess you just need a solution! One of the best new mechanisms for exposing data for flexible querying I have seen is the Open Data Protocol (OData). It will allow consumers to implement their own filtering, sorting and paging over a data source you expose.
Most implementations of this seem to deal with relational data. If you are dealing with a relational data source then OData might be a nice way to go. I suspect by your comment of "expose my aggregate root" that you might be using a document database? If so, there is one example I have seen of OData services on top of MongoDB: http://bloggingabout.net/blogs/vagif/archive/2012/10/11/mongodb-odata-provider-now-supports-arrays-and-nested-collections.aspx.
I hope that helps, OData is definitely worth looking into. It seems to be growing really quickly and is getting good support on both server and client technology platforms.
I'm following these tutorials thoroughly and must say they're great tutorials!
http://www.techchorus.net/create-restful-applications-using-zend-framework
I'm just confused about the whole concept of Zend_Rest abstract methods. In the examples, you only see
index
POST
GET
PUT
DELETE
While these functions make sense, I'm trying to figure out if the whole architecture is only limited to those abstract methods. I'm thinking about a use case where a consumer wants to use the API to update specific fields in lets say the user table, or another case where the consumer wants to update activity table. The business logic of these two tables are covered in one RESTful api controller. I would tackle this problem by creating specific update/post method for each table, and have function parameters to define which fields are being updated. Would this kind of implementation conform with REST and if so how do you go beyond POST,GET, PUT, DELETE methods?
REST architecture does support hierarchical relationships for resources, and your resources are not bound with your database in any way. Your “User” resource might have a subresource “Credentials” that maps to username and password fields in your users table, so you could do a PUT request on “domain.com/users/{userId}/credentials”. You will implement this by creating a controller, say UserCredentials, and the update logic would be in the putAction.
You will have to modify the routing for this to work in Zend though. See How to set up Hierarchical Zend Rest Routes?