friendsofsymfony / fosrestbundle Goto Github PK

The routing loader uses mb_substr(), mb_strotolower() and mb_strtoupper(). Maybe we could use ext/intl for this instead?

A common use case will be adding/editing some resource via Ajax/Ajaj. In this scenario the request will probably return a 200/201 with an url from where the created/edited resource can be GET. Now the flash message should be displayed once the content from the created/edited resource is fetched and displayed. Maybe it would make more sense to write flash messages into a cookie allowing the client to manage (read and remove) flash messages? With a custom rule to ignore the "flash message" cookie for caching it should also be ESI friendly.

Given the following Controller:

/**
 * @rest:NamePrefix("person_")
 */
class PersonController extends Controller {
  public function getAction($id) {
  }
}

The generated route is as follows:

person_get                         GET    /.{_format}

The route should be:

person_get                         GET    /{id}.{_format}

Symfony\Component\Yaml\Yaml::parse() does not exist. Looks like they've moved that logic to a method called load() which takes mixed string or filepath. I'll fix and submit pull.

Currently, if some existing action returns Response object and specific format is requested by Accept: header
the content is thrown at browser as-is, but Content-Type is modifed to reflect requested format.
So ccontent returned to client is html but content-type says it's application/json for example (if json format requested).

This is the side-effect of having RestBundle enabled (and format guessing enabled too). RestBundle
shouldn't set request format in RequestListener if it doesn't do anything to fulfill the demand (because
the response is neither some Exception (which is automatically converted) nor the controller uses
RestBundle\View.

If I enable the SerializerBundle with I get the following error:

Fatal error: Call to undefined method JMS\SerializerBundle\Serializer\SerializerFactory::configureSerializer() in /Library/WebServer/Documents/likracy/app/cache/dev/appDevDebugProjectContainer.php on line 1503

First of all, "custom actions" are RPC, not REST.

I understand that it is convenient tool, but it should be at least marked in README as REST principles violation.

But even if we accept mixing REST and RPC principles, those actions must be POST, not PUT. By HTTP protocol specification PUT is idempotent (as well as GET), which means that if you apply PUT several times it must produce the same outcome.

With custom actions this cannot be guaranteed (consider some simple "toggle" action). For non-idempotent actions you must use POST.

When using the serializer_bundle: true I get a fatal error. I can't track down exactly what's causing this. I'm using Symfony2 RC3 with the use_core branch of https://github.com/lsmith77/SerializerBundle/tree/use_core.

Fatal error: Cannot access private property JMS\SerializerBundle\Serializer\LazyLoadingSerializer::$container in C:\Zend\Apache2\htdocs\hinter\app\cache\dev\appDevDebugProjectContainer.php on line 1769

Thanks

There should be some way to specify that I want all Response objects
returned by actions modified (normalized/serialized) to requested format.

Currently, if action returns Response object (and json format is requested by Accept: header)
the content is thrown at browser as-is, but Content-Type is modifed to reflect requested format.
I mean: content returned to client is html but content-type says it's application/json for example.

I could implement my own onCoreResponse listener to achieve that for my own needs,
but shouldn't this kind of fallback functionality be included in RestBundle?

It's would be mainly useful in cases where I cannot use RestBundle\View (3rd party bundles).
For example FOSUserBundle - it hardcodes responses (and templates used) and this would
give the opportunity to at least convert those responses to format that is meaningfully handleable
by browser app.

Any comments or extra ideas? I don't feel my thoughts regarding this are mature enough at this point.

Move to reST. Organize things in chapters with a quick start guide. also add some sort of diagram to illustrate where in the flow of a request RestBundle hooks in.

Analyze defined routes and generate REST API documentation out of it (maybe with view layer configuration involved - acceptable formats)

wait until the new form stuff is merged

optionally take the validator instance out of a form instance.

step 1) serialize only validator errors if present
step 2) optionally also serialize validation rules (and form fields)

Hi,

When a rest clients submits information to a rest route and won't specify a 'Content-Type' header it would be nice to be able to configure the RestBundle (BodyListener) to fallback to the request '_format' attribute.

I think this should not be default behavior but it would be nice as a configuration option.

License headers should be updated according to FriendsOfSymfony/friendsofsymfony.github.io#14

The so called "HATEOAS Actions" have nothing to do with HATEOAS. They are just regular actions, having some conventional meaning. HATEOAS is about having all possible state transitions expressed as links in resource representation (according to media type definition).

Linking HATEOAS with those actions is misleading and will add even more confusion about REST principles for newbies.

I propose to rename this section to "Conventional actions" and remove any linking to HATEOAS there.

accept headers etc.

After adding the JMSSerializerBundle from the fork prescribed in the README and adding the bundle to the AppKernel, a service not found exception is thrown for jms_serializer_extra.serializer_factory.

To reproduce:

1. Run git submodule add https://github.com/lsmith77/SerializerBundle.git vendor/bundles/JMS/SerializerBundle,
2. Add new JMS\SerializerBundle\JMSSerializerBundle() to app/AppKernel.php
3. Get Exception below

ServiceNotFoundException: You have requested a non-existent service "jms_serializer_extra.serializer_factory"

The controller listener checks the priorities as defined by the actual action matched in the routing system (falls back to global priorities).

see also http://www.informit.com/articles/article.aspx?p=1566460

When keeping in mind that many users will be using the RestBundle's routing to create Restful web applications (not just API's), you need to consider forms in HTML which are the primary drivers of application state for this medium.

Forms don't have the capability to PUT or DELETE (yet) so we should allow some sort of hinting towards these actions. In Zend Framework's implementation of Zend_Rest_Route they simply allow POST requests with ?_method=PUT or ?_method=DELETE appended to the URL. Not necessarily sold on this implementation but think we need to have support for this.

Been working on some stuff for RestBundle, and we're making ~450 assertions in 20 tests. I think there is scope to reduce the number of assertions we make. We dont need to loop over the entire route list thats currently there do we?

Getting an exception when trying to configure a Resource collection according to the README.

Configuration:

users:
  type:     rest
  resource: "@AcmeHello\Controller\UsersController"

comments:
  type:     rest
  parent:   users
  resource: "@AcmeHello\Controller\CommentsController"

Exception:

InvalidArgumentException: Yaml routing loader does not support given key: "parent". 
Expected one of the (type, resource, prefix, pattern, options, defaults, requirements).   

see http://groups.google.com/group/symfony-devs/browse_thread/thread/5af1120c1a6b2ab5 and http://groups.google.com/group/symfony-devs/browse_thread/thread/ebcceb9eb846e08b

https://github.com/FriendsOfSymfony/RestBundle/wiki/VIE-integration

Hi,
When working with the RestBundle and the following config options:

fos_rest:
    serializer_bundle: false
    formats:
        html: false

The following exception is thrown:

[Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException]
  The service "fos_rest.serializer" has a dependency on a non-existent service "".

The simple fix for this seems to be to add a

if ($encoder !== false) 

what can we do to ensure that related links are included in the response? i guess for users using the route generation we can include hypermedia information in a response listener. from there we should also know the Allows etc.

see also

http://getcloudkit.com/curl.html
https://github.com/caelum/restfulie-py/wiki/Hypermedia-Implementation
http://stateless.co/hal_specification.html

probably adapt the code from SecurityExtraBundle

Given the following routing.yml:

phone:
  resource:  Chekote\MyBundle\PhoneController
  type:      rest

person:
  resource:  Chekote\MyBundle\PersonController
  type:      rest

And the following Controllers:

# Chekote/MyBundle/PhoneController.php

/**
 * @rest:Prefix("phone")
 */
class PhoneController extends ContainerAware {
  public function something1Action() {
  }
}

# Chekote/MyBundle/PersonController.php

class PersonController extends ContainerAware {
  public function something2Action() {
  }
}

The following routes are generated:

something1                GET    /phone/something1.{_format}
something2                GET    /phone/something2.{_format}

Since the PersonController was imported after the PhoneController, and the PersonController did not specify it's own Prefix, the RestRouteLoader incorrectly used the prefix previously defined for PhoneController.

or actually maybe there should be a setNewResourceRoute() method as a companion to setRedirectRoute() which only redirects for html and returns a resource created status code and the url for all others?

I see 4 different approaches to this:

1. Automagic
   For this I guess we must somehow realize that one of the parameters is a validator (or form instance with a validator inside) to determine this. It doesnt make sense to do this inside the Serializer, then again it would be the most "convenient" place since there we traverse the parameters.

2. Manual
   An alternative approach would be to optionally support setting a validator/form instance to the setStatusCode() method from which the status code would then be determined, but this would of course require explicit code.

3. Configurable
   Yet another approach would be letting the user configure where in the parameters array the form/validation instance to use for determining the status code can be found:
   symfony/symfony@1ed73fb

4. Manual 2
   Finally another approach could be to simply provide more specialized response classes (FailedValidationResponse) that then need to be manually instantiated and passed to the view layer.

This line is questioned:

$format = $request->getFormat($request->headers->get('Content-Type'));

1. Looks like $request->headers->get('Content-Type') will be always empty (Apache sends it to PHP as $_SERVER['CONTENT_TYPE'] and symfony only writes $SERVER['HTTP...'] vars to headers)
2. Content-Type header may include charset part, e.g. "application/json; charset=UTF-8". In this case format won't be resolved too.

(tried with apache 2.2.17)

Is there any reason why dot is not allowed inside resource id? I was going to use filename as resource id, but discovered that it's impossible with current routing.

When dealing with HATEOS you get these sort of "helper" hypertext actions, i.e. show me a form that will allow me to interact with the resource. This is where new comes in. The complete set of these helpers actions should be:

• new - show me a form that allows me to create or POST a resource at /resource/new
• edit - show me a form that allows me to update or PUT a resource at /resource/{id}/edit
• remove - show me a form that allows me to kill or DELETE a resource at /resource/{id}/remove

This was added to Zend_Rest_Route after some hefty discussions - they started out with just new at first too:

http://framework.zend.com/wiki/display/ZFPROP/Zend_Controller_Router_Route_Rest+-+Luke+Crouch

Since RestBundle supports convention for "collection" of resources, it's logical to add some convention for bulk manipulations with resources in collection.

I see three features here:

1. Create multiple resources with one request (e.g. via import/export tools)
2. Update multiple resources with one request
3. Delete several resources with one request

RestBundle already supports GET for collection, which is supposed to return list of resources in collection.

POST is also supported, but right now it is supposed to create single new resource. I think it's worth mentioning that you can also POST several resources to add all of them to collection.

In theory, PUT to collection should overwrite it completely: e.g. delete all resources in collection and recreate PUTed resources.

Partial collection update is harder, but I believe PATCH method is well suited for this: you can send a set of PATCHes inside request body, which will be mapped and applied to related collection resources.

Bulk delete should be also done as a part of PATCH request to collection, since it partially modifies the collection.
I think bundle already supports most of required features for this, except PATCH method (ticket #50).

This ticket is just for collaboration on the topic, since bulk actions are ofthen done wrong or differently in different implementations, so it probably worth to come with some best practices here.

Also, the collection of resources is pretty generic use-case, so one day we may even want to create custom media-type for such conventional collection, e.g. application/x-collection+json; application/x-collection+xml, etc.

What do you think?

RequestListener has following code:

        if (!$this->serializer->hasDecoder($format)) {
            return;
        }

        $encoder = $this->serializer->getEncoder($format);

But decoders are never added to serializer in FOSRestExtension (only encoders are added). So hasDecoder() will always return false. I guess it should be either hasEncoder / getEncoder or hasDecoder / getDecoder + set decoders in DI extension (which seem more appropriate)

Will probably make it easier to support different configuration formats:
https://github.com/schmittjoh/metadata

Currently you have to setup at least one normalizer for the encoders to work. However even if you do this if the encoder finds at least one object that it can't normalize it throws an exception and that is all you get.

This shouldn't be the default behaviour. I have a simple noopNormalizer here: https://gist.github.com/925912 which at least means I can get some dev done.

Also we need a way to add normalizers. Via configuration seems the simple way, I believe that Lukas has ideas about changing the way the Serializer component works and using the DIC?

For example to deal with the following accept header if text/html isnt supported:

Accept: text/html, text/*; q=0.1

ideally this is provided by core, but if not we might need to add support in this or another bundle

I'm using controllers a s service and a Request is being passed as a dependency into the __construct, because of that service needs to be in request context.

When Routes are being built the scope is not yet of type request so exception is being thrown on
https://github.com/FriendsOfSymfony/RestBundle/blob/master/Routing/Loader/RestRouteLoader.php#L129

Given the following Controller:

/**
 * @rest:Prefix("person")
 * @rest:NamePrefix("person_")
 */
class PersonController extends ContainerAware {
  public function somethingAction() {
  }

  public function getSomething2Action() {
  }
}

The generated routes are as follows:

person_something                   PUT    /something.{_format}
person_get_something2              GET    /person/something2.{_format}

The generated route for somethingAction should have the "/person" prefix, but it does not.

PATCH method is now a part of HTTP protocol (as far as I understand):

http://tools.ietf.org/html/rfc2068#section-19.6.1.1
http://tools.ietf.org/html/rfc5789

So, I believe RestBundle should support routing for this method. Patch may be applied to both - single resource and collection of resources (which is also a resource, just a convention), so both variants should be supported:

patchResources() and patchResource($id)

What do you think?

http://webmachine.basho.com/diagram.html
http://en.wikipedia.org/wiki/List_of_HTTP_status_codes

This is mainly about exception handling. I guess this would require being able to set either an exception as a parameter. Alternatively this could be handled by the ExceptionController. The idea would be to provide a normalizer for Exceptions, which probably requires hardcoded (somehow extensible?) mapping table f.e. Doctrine's OptimisticLockException (HTTP Status code 409).